Re: Moving forward with TDE - Mailing list pgsql-hackers

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.

>     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.

>     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.

> 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.

>     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.

>     >     > 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.

--
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Embrace your flaws.  They make you human, rather than perfect,
  which you will never be.