On Tue, Apr 12, 2022 at 5:30 AM Antonin Houska <ah@cybertec.at> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
> > On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska <ah@cybertec.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 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.
--
Robert Haas
EDB: http://www.enterprisedb.com
