On 10/16/21 18:28, Bruce Momjian wrote:
On Sat, Oct 16, 2021 at 09:15:05AM -0700, Andres Freund wrote:
Hi,
On 2021-10-16 10:16:25 -0400, Bruce Momjian wrote:
As a final comment to Andres's email, adding a GCM has the problems
above, plus it wouldn't detect changes to pg_xact, fsm, vm, etc, which
could also affect the integrity of the data. Someone could also restore
and old copy of a patch to revert a change, and that would not be
detected even by GCM.
I consider this a checkbox feature and making it too complex will cause
it to be rightly rejected.
You're just deferring / hiding the complexity. For one, we'll need integrity
before long if we add encryption support. Then we'll deal with a more complex
on-disk format because there will be two different ways of encrypting. For
another, you're spreading out the security analysis to a lot of places in the
code and more importantly to future changes affecting on-disk data.
I've argued for storing the nonce, but I don't quite see why would we
need integrity guarantees?
AFAICS the threat model the patch aims to address is an attacker who can
observe the data (e.g. a low-privileged OS user), but can't modify the
files. Which seems like a reasonable model for shared environments.
IMO extending this to cases where the attacker can modify the data moves
the goalposts quite significantly. And it's quite possible authenticated
encryption would not be enough to prevent that, because that still works
only at block level, and you can probably do a lot of harm with replay
attacks (e.g. replacing blocks with older versions). And if you can
modify the data directory / config files, what are the chances you can't
just get access to the database, trace the processes or whatever?
We already have a way to check integrity by storing page checksum, but
I'm not sure if that's good enough (there's a lot of subtle issues with
building proper AEAD scheme).
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
