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