Date: Wed, 9 Dec 2020 17:18:37 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Bruce Momjian <bruce@momjian.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Proposed patch for key managment
Message-ID: <20201209221837.GH16415@tamriel.snowman.net>
References: <20201202213814.GG20285@momjian.us>
 <86B6F63B-9594-44F4-AFD8-144BA7FFBC9E@yesql.se>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="nI1Bczae000n5NNi"
Content-Disposition: inline
In-Reply-To: <86B6F63B-9594-44F4-AFD8-144BA7FFBC9E@yesql.se>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


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

Greetings,

* Daniel Gustafsson (daniel@yesql.se) wrote:
> > On 2 Dec 2020, at 22:38, Bruce Momjian <bruce@momjian.us> wrote:
> > Attached is a patch for key management, which will eventually be part of
> > cluster file encryption (CFE), called TDE (Transparent Data Encryption)
> > by Oracle.
>=20
> The attackvector protected against seems to be operating systems users
> (*without* any legitimate database access) gaining access to the data fil=
es.

That isn't the only attack vector that this addresses (though it is one
that this is envisioned to help with- to wit, someone rsync'ing the DB
directory).  TDE also helps with traditional data at rest requirements,
in environments where you don't trust the storage layer to handle that
(for whatever reason), and it's at least imagined that backups with
pg_basebackup would also be encrypted, helping protect against backup
theft.

There's, further, certainly no shortage of folks asking for this.

> Such an attacker would also gain access to postgresql.conf and therefore =
may
> have the cluster passphrase command in case it's stored there.  That would
> imply the attacker is likely (or perhaps better phrased "not entirely
> unlikely") to be able to run that command and decrypt the data *iff* ther=
e is
> no interactive/2fa aspect to the passphrase command.  Is that an accurate
> interpretation?  Do Oracle TDE et.al use a similar setup where an database
> restart require manual intervention?

This is very much an 'it depends' as other products have different
capabilities in this area.  The most similar implementation to what is
being contemplated for PG today would be the big O's "tablespace" TDE,
which offers options of either "Password-based software keystores" (you
have to provide a password when you want to bring that tablespace
online), or "Auto-login software keystores" (there's a "system generated
password" that's used to encrypt the keystore, which seems to be
more-or-less the username and hostname of the system), or HSM based
options.  As such, a DB restart might require manual intervention (if
the keystore is password based, or an HSM that requires manual
involvement) or it might not (auto-login keystore of some kind).

> Admittedly I haven't read the other threads on the topic so if it's discu=
ssed
> somewhere else then I'd appreciate a whacking with a cluestick.

I'm sure it was, but hopefully the above helps you avoid having to dig
through the very (very (very)) long threads on this topic.

Thanks,

Stephen

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

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

iQIcBAEBCgAGBQJf0U08AAoJEO1sijiDR2RVZYgP/jv9xYvniYw641RSlsGFJg4J
8AOeCIL6JoeazyXEFPIR7CN7rc5eKw91/st8c6nARWwu+N7D95dC/3ZBK1PmudjX
jzjDg0Q6SRvyi1hwV0Uex5XMXGwkp99yUC2+W3WLtRTrh/tIEQWfiMCo1UqhIgcp
4vy9jpYByWd/Jka3i/YQtvlpPhk3fCNQhKqRWB7EuEgrG999o622qsi4eyMhvxtd
M6hugy4EsD2+XpjWJx3OjVPh0snWgLAJZy2wcPtu+/xbxVVxvhq9U09afubj+ZOt
JRJ/tbOVi7aJb2TBfybJYplBq3iJLJGZz3DTg7+BoNZaCcIxy+bk7TLRBm/59JBD
/PJ6GRvKs4Q+jwknEqVBHqoQLnd3OvXlGmVQR8PE1ko5lAyF1cuhZwkSarJoOP88
7gp5G0jeShMKeu4yhAGbNk+q7DWRcqI9a/O9Zd5O6OBc474tHsiTM2RbotTGTFIc
ldpWxA2R9f+eltAiw15G/vjEE2geoxiwf+QySLIkOawRSShrc/cHjQiBTTnR9MS+
5fPR83Soc73s4QBvfhTfE0dWoLbHP4l4GJ9Gb8wTdDZpSI4Cq4YMkSLlEtX2yjCe
g7esxVTNFZsF8W2LrCrwyZImU8xDxyjMeJAAmhAV4+zHcMs0Y/DmwN9j+7Vxo3rn
klFx56hHN/SK427IECRc
=0NtY
-----END PGP SIGNATURE-----

--nI1Bczae000n5NNi--