Re: [HACKERS] WIP: Data at rest encryption

On Thu, Jun 15, 2017 at 03:09:32PM -0400, Robert Haas wrote:
> To be honest, I find the hostility toward this feature a bit baffling.
> The argument seems to be essentially that we shouldn't have this
> feature because we'd have to maintain the code and many of the same
> goals could be accomplished by using facilities that already exist
> outside the database server.  But that's also true for parallel query
> (cf. Stado), logical replication (cf. Slony, Bucardo, Londiste),
> physical replication (cf. DRBD), partitioning (cf. pg_partman), RLS
> (cf. veil), and anything that could be written as application logic
> (eg. psql's \if ... \endif, every procedural language we have,
> user-defined functions themselves, database-enforced constraints,
> FDWs).  Yet, in every one of those cases, we find it worthwhile to
> have the feature because it works better and is easier to use when
> it's built in.  I don't think that a patch for this feature is likely
> to be bigger than (or even as large as) the patches for logical
> replication or parallel query, and it will probably be less work to
> maintain going forward than either.

I think the big win for having OS features in the database is
selectivity --- the ability to selectively apply a feature to part of
the database.  This is what you are doing by putting a password on your
SSH key, and my idea about row encryption.

It is also a question of convenience.  If SSH told users they have to
create an encrypted volume to store their SSH keys with a password, it
would be silly, since the files are so small compared to a file system. 
I think the assumption is that any security-concerned deployment of
Postgres will already have Postgres on its own partition and have the
root administrator involved.  I think it is this assumption that drives
the idea that requiring root to run Postgres doesn't make sense, but it
does to do encryption.  Also, there is the sense that security requires
trust of the root user, while using Postgres doesn't require the root
user to also use Postgres.

One serious difference between in-database-encryption and SSH keys is
that the use of passwords for SSH is well understood and reasonable to
use, while I think we all admit that use of passwords for database
objects like SSL keys is murky.  Use of keys for OS-level encryption is
a little better handled, but not as clean as SSH keys.

I admit there is no hard line here, so I guess we will have to see what
the final patch looks like.  I am basing my statements on what I guess
the complexity will be.  Complexity has a cost so we will have to weigh
it when we see it.  When SSH added password access, it was probably an
easy decision because the use-case was high and the complexity was low.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +