Re: [HACKERS] WIP: Data at rest encryption

Bruce,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, Jun 13, 2017 at 03:20:12PM -0400, Stephen Frost wrote:
> > > OK, so let's go back.  You are saying there are no security benefits to
> > > this vs. file system encryption.
> >
> > I'm not sure that I can see any, myself..  Perhaps I'm wrong there, but
> > it seems unlikely that this would be an improvement over filesystem
> > level encryption in the general sense.  I'm not sure that I see it as
> > really worse than filesystem-level encryption either, to be clear.
> > There's a bit of increased information leakage, as Peter mentioned and I
> > agreed with, but it's not a lot and I expect in most cases that
> > information leak would be acceptable.  That seems like something which
> > would need to be considered on a case-by-case basis.
>
> Isn't the leakage controlled by OS permissions, so is it really leakage,
> i.e., if you can see the leakage, you probably have bypassed the OS
> permissions and see the key and data anyway.

The case I'm mainly considering is if you somehow lose control over the
medium in which the encrypted database resides- that is, someone steals
the hard drive, or perhaps the hard drive is sold without properly being
wiped first, things like that.

In such a case, there's no OS permissions to bypass because the OS is
now controlled by the attacker.  In that case, if the key wasn't stored
on the hard drive, then the attacker would be able to see the contents
of the filesystem and the associated metadata, but not the contents of
the cluster.

In that case, the distinction between filesystem-level encryption and
PG-level encryption is that with filesystem-level encryption the
attacker wouldn't be able to even see what files exist or any metadata
about them, whereas with PG-level encryption that information would be
available to the attacker.

In terms of an online attack where an attacker has gained access to the
system then, in general, you're right that if the attacker is able to
see into the PG data directory at all then they've figured out a way to
bypass the OS-level permissions and would then be able to see the data
directly anyway.  That's a different scenario which would most likely be
helped by something like SELinux being used, which could prevent the
attacker from being able to look at the PG data directory because the
attacker has connected to the system from a network which isn't allowed
to directly access those files.

> > > The benefit is allowing configuration
> > > in the database rather than the OS?
> >
> > No, the benefit is that the database administrator can configure it and
> > set it up and not have to get an OS-level administrator involved.  There
> > may also be other reasons why filesystem-level encryption is difficult
> > to set up or use in a certain environment, but this wouldn't depend on
> > anything OS-related and therefore could be done.
>
> OK, my only point here is that we are going down a slippery slope of
> implementing OS things in the database.  There is nothing wrong with
> that but it has often been something we have avoided, because of the
> added complexity required in the db server.

I'm not sure that I actually agree that encryption is really solely an
OS-level function, or even that encryption at rest is solely the OS's
job.  As a counter-example, I encrypt my SSH keys and GPG keys
routinely, even when I'm using OS-level filesystem encryption.  Perhaps
that's excessive of me, but, well, I don't find it so. :)

> As a counter-example, we only added an external collation library to
> Postgres when we clearly saw a benefit, e.g. detecting collation
> changes.

Right, and there's also the potential for adding more flexibility down
the road, which I'm certainly all for, but I see value in having even
this initial version of the feature too.

> > Of course, either way you'd have to provide for a way to get the key
> > from one system to the other.
>
> Uh, doesn't scp do this?  I have trouble seeing how avoiding calling
> openssl justifies changes to our database server.

scp may not be an option as it requires network connectivity between the
systems.  This is also just one of the use-cases, and not the main
reason, at least in my view, to add this feature.

> > Also, tools like pg_basebackup could be used, with nearly zero changes,
> > I think, to get an encrypted copy of the database for backup purposes,
> > removing the need to work out a way to handle encrypting backups.
>
> I do think we need much more documentation on how to encrypt things,
> though that is a separate issue.  It might help to document how you
> _should_ do things now to see the limitations we have.

Improving our documentation would certainly be good, but I'm not sure
that we can really recommend specific ways of doing things like
filesystem-level encryption, as that's really OS-dependent and there
could be trade-offs in different ways a given OS might provide that
capability.  I'm not sure that having our documentation generically say
"you should use filesystem-level encryption" would really be very
helpful.

Perhaps I misunderstood your suggestion here though..?

> > > Is the problem that you have to encrypt before sending and decrypt on
> > > arrival, if you don't trust the transmission link?  Is that used a lot?
> > > Is having the db encrypt every write a reasonable solution to that?
> >
> > There's multiple use-cases here.  Making it easier to copy the database
> > is just one of them and it isn't the biggest one.  The biggest benefit
> > is that there's cases where filesystem-level encryption isn't really an
> > option or, even if it is, it's not desirable for other reasons.
>
> I am thinking NAS storage you don't trust, though there is the leakage
> there.

Yes, NAS or SAN storage where you don't want the NAS/SAN administrators
to have access to the data is a good example of where encryption would
be useful.  Of course, either filesystem-level or PG-level encryption
would address that, but with the trade-off that PG-level encryption
would allow the NAS/SAN administrators to see the file metadata, as
discussed above.

> > > As far as future features, we don't have to add the all features at this
> > > time, but if someone has a good idea for an API and we can make it work
> > > easily while adding this feature, why wouldn't we do that?
> >
> > Sure, I'm all for specific suggestions about how to improve the API, or
> > just in general recommendations of how to improve the patch.  The
> > suggestions which have been made about key management don't really come
> > across to me as specific API-level recommendations but rather "this
> > would also be nice to have" kind of comments, which isn't really the
> > same.
>
> They are related, or you can't even know that because you are/were
> preventing the discussion from happening.  As an example, full-cluster
> encryption doesn't really add any new capabilities, maybe just easier
> deployment for some users.  Where things get useful is fine-grained
> encryption, which file system-level encryption can't do.

I agree that having fine-grained control would be helpful, but as I was
trying to get at, that's going to involve new catalog tables and SQL
syntax, and we'd still need to address how to encrypt the cluster-wide
files anyway, which is what this patch is working to do.

> Also, has anyone asked users if they would find db-encryption better
> than file system encryption?

I've been asked for this capability multiple times from our users and
have generally pushed back and encouraged filesystem-level encryption.
That hasn't always been an acceptable solution, unfortunately.

Thanks!

Stephen