Date: Wed, 13 Apr 2022 11:49:16 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Antonin Houska <ah@cybertec.at>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Temporary file access API
Message-ID: <20220413154916.GI10577@tamriel.snowman.net>
References: <4987.1644323098@antos>
 <20220301143431.GT10577@tamriel.snowman.net>
 <27013.1646738099@antos>
 <CA+TgmobnojZw6mZi0T_61RtUDgsxroYhp+DJU5Yhz6caxUrQgw@mail.gmail.com>
 <3146.1649408068@antos>
 <CA+TgmobQM4Yym3944tFpcaJX4EfYs92Vv4NCY3V0R5BE4RU2rg@mail.gmail.com>
 <2132.1649664364@antos>
 <CA+TgmoaJ74opLkguCmm+Du9T1mAPtPYThCQhF_bbhZW5i4VAkg@mail.gmail.com>
 <3690.1649755839@antos>
 <CA+TgmobFVyBNxhsYOteJ-KdvkYyTGU4WUZv=y2VwmmahNyMUsA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="TEnxaPCmSubUceV2"
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmobFVyBNxhsYOteJ-KdvkYyTGU4WUZv=y2VwmmahNyMUsA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220413154916.GI10577%40tamriel.snowman.net>
Precedence: bulk


--TEnxaPCmSubUceV2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Robert Haas (robertmhaas@gmail.com) wrote:
> 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_o=
f_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=3Dpostgresql.git;a=3Dcommit;h=3D58=
91c7a8ed8f2d3d577e7eea34dacff12d7b6bbd
>=20
> 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.
>=20
> 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=
=2E)
>=20
> 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

--TEnxaPCmSubUceV2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJiVvD8AAoJEO1sijiDR2RVy1YP+wbwhSs4exS9PHEJ1Zciibeu
fG7Vz9iM1HaJke6xYdL431DFt1C24UTTP55NcaaJOGQibcgnymheN26My/E3VUAt
oaCTdqb94d4OPR4WwCe1OSEjekrDjZAhgG2WZHhukn5NQGrkhcbAb9P40NPlrFMh
yJIP3eMSYPWcn8rIHTx+JQhWAwbgXfMvBLbGv73QPN321ESf+iUm9Vy0m7NmaSS9
X3859+4ERFRq5QzTdHC+u16QExoC8ZgGpyi/1spaDIsk/Dhv5qsJ4xtvncBR343f
uZGaH/s28R5oxifTfKmtI7qNjoRUjQUsQQTYF1Mq7Aw5ST0rYc1OS2sgp7L2YDn8
M+GuxawzfuqQQUDpw+uTBJUPovcojITK83c3K9T5BFmKXmUoowSLtS0D+hT6evIY
hY43jVvgHLdCC8SAsl4GnxvFpUyaC+P8HPrNwU0pBoLAqlNIob1uAlt7iWNEgkN4
7KxEOUhW9yUWQF3xG8kob79i+9C7DOtf9u73hBkcaaetxq0bsgul89ryn957mMHV
n1zgMurkOUwJ4s8IWa43V7VcHXSBfRxuZmojdJG3h9qD3Jx1ZyhD653eninBsfRC
G7wvg0JOjyv41W4mvPphO9DokaQv+UJCnaq7NjNzZwsn+PyHg6kAv5xz9ifTKNOg
E3Etdwc3m+UVzpcif8Za
=qm7G
-----END PGP SIGNATURE-----

--TEnxaPCmSubUceV2--