Re: storing an explicit nonce

Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, May 25, 2021 at 08:03:14PM -0400, Stephen Frost wrote:
> > Indeed they are, but that's not relevant to the thrust of this specific
> > debate.
> > 
> > Bruce is arguing that because clog is unprotected that it's not useful
> > to protect relation data, with regard to data integrity validation as
> > provided by AES-GCM using/storing tags.  I dispute this, as relation
> > data is primary data while clog, for all its value, is still metadata.
> > Yes, impacting the metadata has an impact on the primary data, but it
> > doesn't *change* that primary data at its core (and it's also more
> > likely to be detected than random bit flipping in the relation data
> > would be, which is possible if you're only encrypting and not providing
> > any integrity validation).
> 
> Even if you can protect clog, this documentation paragraph makes it
> clear that if you can modify the cluster, you can weaken security enough
> to read and write any data you want:
> 
> https://github.com/postgres/postgres/compare/master..bmomjian:_cfe-01-doc.patch
> 
> 	Cluster file encryption does not protect against unauthorized
> 	file system writes.  Such writes can allow data decryption if
> 	used to weaken the system's security and the weakened system is
> 	later supplied with the externally-stored cluster encryption key.
> 	This also does not always detect if users with write access remove
> 	or modify database files.

This is clearly a different consideration than the concern around clog
and speaks to the issues with how we fetch and maintain the key- things
which we can and really should be better about than what is currently
being done, and which I do believe we will improve upon.

> I know of no way to make that safer, so again, I don't see the value in
> modification detection.  Maybe someday we would find a way, but it seems
> so remote as to not warrant consideration.

I'm rather baffled by the comment that there's 'no way to make that
safer'.  Giving users a way to segregate actual data from configuration
and commands would greatly improve the situation by making it much more
difficult for a user who only has access to the data directory, where
much of the data is encrypted and protected against data maniupulation
using proper tags, to capture the encryption key.

The concerns which are not actually discussed in the paragraph above
relate to how the key is handled- specifically that we run some external
command that the user provides to fetch it, and that command can be
overridden via postgresql.auto.conf that lives in the data directory.
That's not a terribly safe thing to do and we can certainly do better,
and without all that much difficulty if we actually look at doing so.

A very simple approach would be to just require that the command to
fetch the encryption key come from postgresql.conf and then simply
encrypt+protect postgresql.auto.conf.  We'd then document that the user
needs to ensure they have appropriate protection of postgresql.conf,
which could and probably should live elsewhere.

I'd like to see us incrementally move in the direction of providing a
way for users, probably advanced ones to start but hopefully eventually
getting to a point that you don't have to be an advanced user, to
implement a reasonably secure solution which provides both
confidentiality and integrity.  We do not have to solve all of these
things in the first release, but I don't think we should be talking
today about tossing out the idea that, some day down the road, we could
have a robust system which provides both.

Thanks,

Stephen