Re: Temporary file access API

Greetings,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Tue, Apr 12, 2022 at 5:30 AM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > > On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> > > > There are't really that many kinds of files to encrypt:
> > > >
> > > > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_contain_user_data
> > > >
> > > > (And pg_stat/* files should be removed from the list.)
> > >
> > > This kind of gets into some theoretical questions. Like, do we think
> > > that it's an information leak if people can look at how many
> > > transactions are committing and aborting in pg_xact_status? In theory
> > > it could be, but I know it's been argued that that's too much of a
> > > side channel. I'm not sure I believe that, but it's arguable.
> >
> > I was referring to the fact that the statistics are no longer stored in files:
> >
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd
>
> Oh, yeah, I agree with that. I was saying that I'm not altogether a
> believer in the idea that we need not encrypt SLRU files.
>
> TBH, I think that no matter what we do there are going to be side
> channel leaks, where some security researcher demonstrates that they
> can infer something based on file length or file creation rate or
> something. It seems inevitable. But the more stuff we don't encrypt,
> the easier those attacks are going to be. On the other hand,
> encrypting more stuff also makes the project harder. It's hard for me
> to judge what the right balance is here. Maybe it's OK to exclude that
> stuff for an initial version and just disclaim the heck out of it, but
> I don't think that should be our long term strategy.

I agree that there's undoubtably going to be side-channel attacks, some
of which we may never be able to address, but we should be looking to
try and do as much as we can while also disclaiming that which we can't.

I'd lay this out in steps along these lines:

- Primary data is encrypted (and, ideally, optionally authenticated)

This is basically what the current state of things are with the
patches that have been posted in the past and would be a fantastic first
step that would get us past a lot of the auditors and others who are
unhappy that they can simply 'grep' a PG data directory for user data.
This also generally addresses off-line attacks, backups, etc. This also
puts us on a similar level as other vendors who offer TDE, as I
understand it.

- Encryption / authentication of metadata (SLRUs, maybe more)

This would be a great next step and would move us in the direction of
having a system that's resiliant against online storage-level attacks.
As for how to get there, I would think we'd start with coming up with a
way to at least have good checksums for SLRUs that are just generally
available and users are encouraged to enable, and then have that done in
a way that we could store an authentication tag instead in the future.

> > > I really don't know how you can argue that pg_dynshmem/mmap.NNNNNNN
> > > doesn't contain user data - surely it can.
> >
> > Good point. Since postgres does not control writing into this file, it's a
> > special case though. (Maybe TDE will have to reject to start if
> > dynamic_shared_memory_type is set to mmap and the instance is encrypted.)
>
> Interesting point.

Yeah, this is an interesting case and it really depends on what attack
vector is being considered and how the system is configured. I don't
think it's too much of an issue to say that you shouldn't use TDE with
mmap (I'm not huge on the idea of explicitly preventing someone from
doing it if they really want though..).

Thanks,

Stephen