Re: Key management with tests - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Key management with tests |
Date | |
Msg-id | 20210206005318.GC8777@momjian.us Whole thread Raw |
In response to | Re: Key management with tests (Stephen Frost <sfrost@snowman.net>) |
Responses |
Re: Key management with tests
|
List | pgsql-hackers |
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. > Each of these steps is a useful improvement in its own right and will > open up more opportunities for PG to be used. It wasn't my intent to > suggest otherwise, but rather to see if there was an opportunity to get > a few things done at once if it wasn't too impactful. I agree now that > it makes sense to focus on the first step, so we can hopefully get that > accomplished. OK, good. > > I think postmaster.opts is used for pg_ctl reload. I think the question > > is whether the value of maliciously writable PGDATA being able to read > > the keys, while not protecting or detecting all malicious > > writes/db-modifications, is worth it. And, while I listed the files > > above, there are probably many more ways to break the system. > > postmaster.opts is used for pg_ctl restart, just to be clear. Yes, sorry, "restart". > As I try to state above- I don't think we need to provide any specific > protections against a malicious writer for plain encryption to be > useful for some important use-cases. Providing protections against a > malicious writer being able to access the keys is certainly important > as, if they acquire the keys, they would be able to trivially both > decrypt the data and modify any other data they wished to, so it seems > likely that solving that would be the first step towards protecting > against a malicious writer, after which it's useful to think about what > else we could provide integrity checking of, and principal data strikes > me as the next sensible step, followed by what's essentially metadata. Agreed. > > See above --- I think we can't just say we close _most_ of the doors > > here, and I am afraid there will be more and more cases we miss. It > > feels too open-ended. For example, imagine modifying a PGDATA file so > > it is a symbolic link to another file that is not in PGDATA? Seems that > > would break all sorts of security restrictions, and that's just a new > > idea I came up with today. > > It's not clear how that would provide the attacker with much, if > anything. Not sure myself either. > > What I don't want to do is to add a lot of complexity to the system, and > > not really gain any meaningful security. > > Integrity is very meaningful to security, but key management would > certainly come first because if an attacker is able to acquire the keys > then they can circumvent any integrity check being done by simply using > the key. I appreciate that protecting the keys is non-trivial but it's > absolutely critical as everything else falls apart if the key is > compromised. I don't think we should be thinking that we're going to be Agreed, > done with key management or with providing ways to acquire keys even if > the currently proposed patches go in- we'll undoubtably need to provide > other options in the future. There's an interesting point in this > regarding how the flexibility of the shell-script based approach also > introduces this risk that an attacker could modify it and write the key > out to somewhere that they could get at pretty easily. Having support > for directly fetching the key from the Linux kernel or the various > vaulting systems would avoid this risk, I would think. Maybe there's a Agreed. > way to get PG to dump the key out of system memory by modifying other > files in PGDATA but that's surely quite a bit more difficult. > Ultimately, I don't think this voids the proposed approach but I do > think it means we'll want to improve on this in the future. OK. I was just saying we can't be sure we can improve it. > > Oh, that is a very meaningful lesson. I do think that for cluster file > > encryption, if we have a vulnerability, someone will write a script for > > it, and it could be widely exploited. I think RLS gets a little more > > flexibility since someone is already in the database when using it. > > In the current attack we're contemplating, the attacker's got write > access to the filesystem and if that's happening then they've managed to > get through a few layers already, I would think, so it seems unlikely > that it would be widely exploited. Of course, we'd like to avoid having Agreed. > vulnerabilities where we can, but a particular behavior is only a > vulnerabiliy if there's an expectation that we protect against that kind > of attack, which is why documentation is extremely important, which is > what I was trying to get at with the RLS example. True. > > I am not against adding more security features, but I need agreement > > that the existing features/protections, with the planned source code > > impact, is acceptable. I don't want to go down the road of getting the > > feature with the _hope_ that later changes will make the feature > > acceptable --- for me, either what we are planning now is acceptable > > given its code impact, or it is not. If the feature is not sufficient, > > then I would not move forward until we had a reasonable plan of when the > > feature would have acceptable usefulness, and acceptable source code > > impact. > > See above. I do think that the proposed approach is a valuable > capability and improvement in its own right. It seems likely that this > first step, as proposed, would allow us to support use-cases such as the > PCI one you mentioned previously. Taking it further and adding > integrity validation would move us into even more use-cases as it would > address NIST requirements which explicitly call for confidentiality and > integrity. Good. I wanted to express this so everyone is clear on what we are doing, and what we are not doing but might be able to do in the future. > > The big problem, as you outlined above, is that adding to the > > protections, like malicious write detection for a remote PGDATA, greatly > > increases the code impact, and ultimately, might be unsolvable. > > I don't think we really know that it increases the code impact hugely or > is unsolveable, but ultimately those are really debates for another day > at this point. True. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
pgsql-hackers by date: