Re: Key management with tests - Mailing list pgsql-hackers

On Wed, Feb  3, 2021 at 01:16:32PM -0500, Bruce Momjian wrote:
> On Wed, Feb  3, 2021 at 10:33:57AM -0500, Stephen Frost wrote:
> > I doubt anyone would actually stipulate that they *guarantee* detection
> > of malicious writes, and I don't think we should either, but certainly
> > the other systems which provide TDE do so in a manner that provides both
> > confidentiality and integrity.  The big O, at least, documents that they
> > use SHA-1 for their integrity checking, though they also provide an
> > option which disables it.  If we used an additional fork to provide the
> > integrity then we could also give users the option of either having
> > integrity included or not.
> 
> I thought more about this at an abstract level.  If you are worried
> about malicious users _reading_ data, you can encrypt the sensitive
> parts, e.g., heap/index/WAL/temp, and leave some unencrypted, like
> pg_xact.  Reading pg_xact is pretty useless if you can't read the heap
> pages.  Reading postgresql.conf.auto, the external key retrieval
> scripts, etc. are useless too.
> 
> However, when you are trying to protect against write access, you have
> to really encrypt _everything_, because the system is very
> interdependent, and changing one part where _reading_ is safe can affect
> other parts that must remain secure.  You can modify
> postgresql.conf.auto to capture the cluster key, or maybe even change
> something to dump out the data keys from memory.  You can modify pg_xact
> to affect how heap pages are interpreted.
> 
> My point is that being able to detect malicious heap/index writes really
> doesn't gain us any security since there are much more serious writes
> that can be made, and protecting against those more serious writes would
> cause unacceptable Postgres source code changes which will probably
> never be implemented.

I looked further.  First, I don't think we are going to be able to
protect at all against users who have _write_ access on the OS running
Postgres.  It would be too easy to just read process memory, or modify
~/.profile.

I think the only possible option would be to try to give some protection
against users with write access to PGDATA, where PGDATA is on another
server, e.g., via NFS.  We can't protect against all db modifications,
for reasons outlined above, but we might be able to protect against
write users being able to _read_ the keys and therefore decrypt data. 
Looking at PGDATA, we have, at least:

    postgresql.conf
    pg_hba.conf
    postmaster.opts
    postgresql.conf.auto

which could be exploited to cause reading of the cluster key or process
memory.  The first two can be located outside of PGDATA but the last two
currently cannot.

The problem is that this is a limited use-case, and there are probably
other problems I am not considering.  It seems too error-prone to even
try protect against this, but it does limit the value of this feature.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee