On 3/26/14, Carlos Espejo <carlosespejo@xxxxxxxxx> wrote: > Anybody running their PostgreSQL server from a ecryptfs container? What are > the common production setups out there? What are the drawbacks that people > have experienced with their solution? I ran a couple web servers off Full Disk Encryption (FDE) installs, and I don't recommend that - if the host or VM needs restarting, you need a side-channel login (which could possibly be an expensive on-site admin call depending on your contract) to get past the kernel's "please enter disk password" prompt, which I find very not-enjoyable. Running an encrypted filesystem of some sort after normal bootup means that, at the least, you ought be able to SSH in to fix up any misconfigurations or enter encrypted volume passwords etc. I have not use ecryptfs, but it looks like a newer version of encfs or at least similar in design. I used to use encfs a few years ago, but it has known security limitations and is no longer advised for applications requiring genuine security. I cannot speak to ecryptfs. I note in the Debian package description/manifest for encfs it says "Encrypted data is stored within the native file system, thus no fixed-size loopback image is required." Certainly ecryptfs appears to share this (from a utility perspective advantageous trait, that is, the lack of requirement for a fixed size loopback file, but in addition, the ability to transfer individual files from one filesystem to another (perhaps for backup purposes). I would add to that list a distinct likelihood that the 'encrypted' files are perhaps more amenable to incremental backup, whereas an encrypted loopback filesystem-in-a-file may be harder to achieve incremental backups with - though by no means impossible - it's just different, and depends on whose doing your backups, who you want to have keys etc. HOWEVER1: there is usually the limitation with per-file encryption systems, that certain metadata of the files being encrypted is visible (not encrypted) - for example, the file name, access perms, ownership, fair estimate of file size, and quite probably other things like ACLs (if you use those). Each of these may or may not be of concern to you or to your particular threat models. HOWEVER2: when creating certain encrypted loopback containers, it is almost trivial to create a sparse file for your 'encrypted container' (in my experience - dd does the job nicely thank you very much), and to then set that up as a loopback encrypted device (use your standard procedure here), and finally just format your crypted container (with chosen filesystem) in your chosen filesystem's "quick format" mode (ie, effectively sparse). Truecrypt (not libre by Debian's standards) used to provide such a 'sparse' type mode. It is still possible (at least on GNU/Linux) to manually use truecrypt (or fully libre tcplay) at the command line to achieve this with 'truecrypt' volumes. But sparse containers have their own security issues too. There are tradeoffs no matter what you do - convenience, speed, security and more. You will need to do some substantial reading/research if you have genuine threat/need for encrypted data store. Conclusion: there are pros and cons all around - you DO have a threat model don't you? :) Good luck, Zenaan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
