Re: Key management with tests

On Fri, Feb 5, 2021 at 07:53:18PM -0500, Bruce Momjian wrote:
> On Fri, Feb 5, 2021 at 05:21:22PM -0500, Stephen Frost wrote:
> > > I disagree. If we only warn about some parts, attackers will just
> > > attack other parts. It will also give users a false sense of security.
> > > If you can get the keys, it doesn't matter if there is one or ten ways
> > > of getting them, if they are all of equal difficulty. Same with
> > > modifying the system files.
> >
> > I agree that there's an additional concern around the keys and that we
> > would want to have a solid way to avoid having them be compromised. We
> > might not be able to guarantee that attackers who can write to PGDATA
> > can't gain access to the keys in the first implementation, but I don't
> > see that as a problem- the TDE capability would still provide protection
> > against improper disposal and some other use-cases, which is useful. I
>
> Agreed.
>
> > do think it'd be useful to consider how we could provide protection
> > against an attacker who has write access from being able to acquire the
> > keys, but that seems like a tractable problem. Following that, we could
> > look at how to provide integrity checking for principal data, using one
> > of the outlined approaches or maybe something else entirely. Lastly,
> > perhaps we can find a way to provide confidentiality and integrity for
> > other parts of the system.
>
> Yes, we should consider it, and I want to have this discussion. Ideally
> we could implement that now, because it might be harder later. However,
> I don't see how we can add additional security protections without
> adding a lot more complexity. You are right we might have better ideas
> later.

I added a Limitations section so we can consider future improvements:

https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#Limitations

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

The usefulness of a cup is in its emptiness, Bruce Lee