Re: Disk Encryption in Production - Mailing list pgsql-general

On 3/26/14, Carlos Espejo <carlosespejo@gmail.com> 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