Re: Key management with tests

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(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

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