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 <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee