Re: Moving forward with TDE

Greetings,

On Mon, Mar 27, 2023 at 21:35 Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Tue, Mar 28, 2023 at 02:03:50AM +0200, Stephen Frost wrote:
> > The remote storage is certainly an independent system. Multi-mount LUNs
> are
> > entirely possible in a SAN (and absolutely with NFS, or just the NFS
> server
> > itself is compromised..), so while the attacker may not have any access
> to the
> > database server itself, they may have access to these other systems, and
> that’s
> > not even considering in-transit attacks which are also absolutely
> possible,
> > especially with iSCSI or NFS.
> >
> > I don’t understand what is being claimed that the remote storage is “not
> an
> > independent system” based on my understanding of, eg, NFS. With NFS, a
> > directory on the NFS server is exported and the client mounts that
> directory as
> > NFS locally, all over a network which may or may not be secured against
> > manipulation. A user on the NFS server with root access is absolutely
> able to
> > access and modify files on the NFS server trivially, even if they have no
> > access to the PG server. Would you explain what you mean?
>
> The point is that someone could change values in the storage, pg_xact,
> encryption settings, binaries, that would allow the attacker to learn
> the encryption key. This is not possible for two secure endpoints and
> someone changing data in transit. Yeah, it took me a while to
> understand these boundaries too.

This depends on the specific configuration of the systems, clearly. Being
able to change values in other parts of the system isn’t great and we
should work to improve on that, but clearly that isn’t so much of an issue
that people aren’t willing to accept a partial solution or existing
commercial solutions wouldn’t be accepted or considered viable. Indeed,
using GCM is objectively an improvement over what’s being offered commonly
today.

I also generally object to the idea that being able to manipulate the
PGDATA directory necessarily means being able to gain access to the KEK. In
trivial solutions, sure, it’s possible, but the NFS server should never be
asking some external KMS for the key to a given DB server and a reasonable
implementation won’t allow this, and instead would flag and log such an
attempt for someone to review, leading to a much faster realization of a
compromised system.

Certainly it’s much simpler to reason about an attacker with no knowledge
of either system and only network access to see if they can penetrate the
communications between the two end-points, but that is not the only case
where authenticated encryption is useful.

> So the idea is that the backup user can be compromised without the
> data
> > being vulnerable --- makes sense, though that use-case seems narrow.
> >
> > That’s perhaps a fair consideration- but it’s clearly of enough value
> that many
> > of our users are asking for it and not using PG because we don’t have it
> today.
> > Ultimately though, this clearly makes it more than a “checkbox” feature.
> I hope
> > we are able to agree on that now.
>
> It is more than a check box feature, yes, but I am guessing few people
> are wanting the this for the actual features beyond check box.

As I explained previously, perhaps the people asking are doing so for only
the “checkbox”, but that doesn’t mean it isn’t a useful feature or that it
isn’t valuable in its own right. Those checklists were compiled and
enforced for a reason, which the end users might not understand but is
still absolutely valuable. Sad to say, but frankly this is becoming more
and more common but we shouldn’t be faulting the users asking for it- if it
were truly useless then eventually it would be removed from the standard,
but it hasn’t and it won’t be because, while not every end user has a depth
of understanding to explain it, it is actually a useful and important
capability to have and one that is important to implement.

> Yes, there is value beyond the check-box, but in most cases those
> > values are limited considering the complexity of the features, and
> the
> > check-box is what most people are asking for, I think.
> >
> > For the users who ask on the lists for this feature, regularly, how many
> don’t
> > ask because they google or find prior responses on the list to the
> question of
> > if we have this capability? How do we know that their cases are
> “checkbox”?
>
> Because I have rarely heard people articulate the value beyond check
> box.

Have I done so sufficiently then that we can agree that calling it
“checkbox” is inappropriate and detrimental to our user base?

> Consider that there are standards groups which explicitly consider these
> attack
> > vectors and consider them important enough to require mitigations to
> address
> > those vectors. Do the end users of PG understand the attack vectors or
> why they
> > matter? Perhaps not, but just because they can’t articulate the
> reasoning does
> > NOT mean that the attack vector doesn’t exist or that their environment
> is
> > somehow immune to it- indeed, as the standards bodies surely know, the
> opposite
> > is true- they’re almost certainly at risk of those attack vectors and
> therefore
> > the standards bodies are absolutely justified in requiring them to
> provide a
> > solution. Treating these users as unimportant because they don’t have
> the depth
> > of understanding that we do or that the standards body does is not
> helping
> > them- it’s actively driving them away from PG.
>
> Well, then who is going to explain them here, because I have not heard
> them yet.

I thought I was doing so.

> The RLS arguments were that queries could expoose some of the
> underlying
> > data, but in summary, that was considered acceptable.
> >
> > This is an excellent point- and dovetails very nicely into my argument
> that
> > protecting primary data (what is provided by users and ends up in
> indexes and
> > heaps) is valuable even if we don’t (yet..) have protection for other
> parts of
> > the system. Reducing the size of the attack vector is absolutely useful,
> > especially when it’s such a large amount of the data in the system. Yes,
> we
> > should, and will, continue to improve- as we do with many features, but
> we
> > don’t need to wait for perfection to include this feature, just as with
> RLS and
> > numerous other features we have.
>
> The issue is that you needed a certain type of user with a certain type
> of access to break RLS, while for this, writing to PGDATA is the simple
> case for all the breakage, and the thing we are protecting with
> authentication.

This goes back to the “if it isn’t perfect then it’s useless” argument …
but that’s exactly the discussion which was had around RLS and ultimately
we decided that RLS was still useful even with the leaks- and our users
accepted that also and have benefitted from it ever since it was included
in core. The same exists here- yes, more needs to be done than the absolute
simplest “make install” to have the system be secure (not unlike today with
our defaults from a source build with “make install”..) but at least with
this capability included it’s possible, and we can write “securing
PostgreSQL” documentation on how to, whereas without it there is simply no
way to address the attack vectors I’ve articulated here.

> > > We, as a community, are clearly losing value by lack of this
> > capability,
> > > if by
> > > > no other measure than simply the numerous users of the
> commercial
> > > > implementations feeling that they simply can’t use PG
> without this
> > > feature, for
> > > > whatever their reasoning.
> > >
> > > That is true, but I go back to my concern over useful feature
> vs.
> > check
> > > box.
> > >
> > > While it’s easy to label something as checkbox, I don’t feel we
> have been
> > fair
> >
> > No, actually, it isn't. I am not sure why you are saying that.
> >
> > I’m confused as to what is required to label a feature as a “checkbox”
> feature
> > then. What did you us to make that determination of this feature? I’m
> happy to
> > be wrong here.
>
> I don't see the point in me continuing to reply here. You just seem to
> continue asking questions without actually thinking of what I am saying,
> and hope I get tired or something.

I hope we have others who have a moment to chime in here and provide their
viewpoints as I don’t feel this is an accurate representation of the
discussion thus far.

Thanks,

Stephen

>