Re: WIP: Data at rest encryption

Bruce,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Thu, Jun 15, 2017 at 05:04:17PM -0400, Robert Haas wrote:
> > > 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.
> >
> > I don't understand this. It is certainly true that you're running
> > binaries owned by root, the root user could Trojan the binaries and
> > break any security you think you have. But that problem is no better
> > or worse for PostgreSQL than anything else.
>
> I couldn't find a cleaner way to see it --- it is that database use
> doesn't involve the root user using it, while database security requires
> the root user to also be security-conscious.

I tend to agree with Robert here (in general). Further, there are
certainly environments where the administrator with root access is
absolutely security conscious, but that doesn't mean that the DBA has
easy access to the root account or to folks who have that level of
access and it's much easier for the DBA if they're able to address all
of their requirements by building PG themselves, installing it, and,
ideally, encrypting the DB.

> > > 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.
> >
> > Peter pointed out upthread that our handling of SSL passphrases leaves
> > a lot to be desired, and that maybe we should fix that problem first;
> > I agree. But I don't think this is any kind of intrinsic limitation
> > of PostgreSQL vs. encrypted filesystems vs. SSH; it's just a
> > quality-of-implementation issue.

I'm not thrilled with asking Ants to implement a solution to SSL
passphrases, and generalizing it to work for this, to get this feature
accepted. I assume that the reason for asking for that work to be done
now is because we decided that the current approach for SSL sucks but we
couldn't actually drop support for it, but we don't want to add other
features which work in a similar way because, well, it sucks.

I get that. I'm not thrilled with it, but I get it. I'm hopeful it
ends up not being too bad, but if it ends up meaning we don't get this
feature, then I'll reconsider my position about agreeing that it's an
acceptable requirement.

> I think there are environmental issues that make password use on SSH
> easier than the other cases --- it isn't just code quality. However, it
> would be good to research how SSH handles it to see if we can get any
> ideas.

Actually, the approach SSH uses is a really good one, imv, and one which
we might be able to leverage.. I'm not sure though. I will say that,
in general, I like the idea of leveraging the external libraries which
handle keys and deal with encryption to make this happen as those allow
things like hardware devices to hold the key and possibly perform the
encryption/decryption, etc.

Thanks!

Stephen