Re: Proposed patch for key managment

On Sat, Dec 19, 2020 at 11:45:08AM +0000, Alastair Turner wrote:
> On Fri, 18 Dec 2020 at 21:36, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > These ideas don't seem too bad but I'd think we'd pass which key we want
> > on the command-line using a %i or something like that, rather than using
> > stdin, unless there's some reason that would be an issue..? Certainly
> > the CLI utilities I've seen tend to expect the name of the secret that
> > you're asking for to be passed on the command line.
>
> Agreed. I was working on the assumption that the calling process
> (initdb or pg_ctl) would have access to the challenge material and be
> passing it to the utility, so putting it in a command line would allow
> it to leak. If the utility is accessing the challenge material
> directly, then just an indicator of which key to work with would be a
> lot simpler, true.

I want to repeat here what I said in another thread:

> I think ultimately we will need three commands to control the keys.
> First, there is the cluster_key_command, which we have now. Second, I
> think we will need an optional command which returns random bytes ---
> this would allow users to get random bytes from a different source than
> that used by the server code.
>
> Third, we will probably need a command that returns the data encryption
> keys directly, either heap/index or WAL keys, probably based on key
> number --- you pass the key number you want, and the command returns the
> data key. There would not be a cluster key in this case, but the
> command could still prompt the user for perhaps a password to the KMS
> server. It could not be used if any of the previous two commands are
> used. I assume an HMAC would still be stored in the pg_cryptokeys
> directory to check that the right key has been returned.
>
> I thought we should implement the first command, because it will
> probably be the most common and easiest to use, and then see what people
> want added.

There is also a fourth option where the command returns multiple keys,
one per line of hex digits. That could be written in shell script, but
it would be fragile and complex. It could be written in Perl, but that
would add a new language requirement for this feature. It could be
written in C, but that would limits its flexibility because changes
would require a recompile, and you would probably need that C file to
call external scripts to tailor input like we do now from the server.

You could actually write a full implemention of what we do on the server
side in client code, but pg_alterckey would not work, since it would not
know the data format, so we would need another cluster key alter for that.

It could be written as a C extension, but that would be also have C's
limitations. In summary, having the server do most of the complex work
for the default case seems best, and eventually allowing the ability for
the client to do everything seems ideal. I think we need more input
before we go beyond what we do now.

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

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