Re: Key management with tests

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Subject: Re: Key management with tests
Date: 2021-02-07 19:00:51
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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:

Bruce Momjian <bruce(at)momjian(dot)us>

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-02-07 19:05:27 Re: Bug in query rewriter - hasModifyingCTE not getting set
Previous Message Tom Lane 2021-02-07 18:55:00 Re: Support tab completion for upper character inputs in psql