Re: Hiding a GUC from SQL

On Sun, Jun 21, 2020 at 10:21 PM raf <raf(at)raf(dot)org> wrote:

> Laurenz Albe wrote:
>
> > > But only mostly useless. :-) There are ways to limit the power of the
> > > superuser. On Linux, for instance, "sysctl kernel.yama.ptrace_scope=3"
> > > prevents tracing, debugging, and reading another process's memory, even
> > > by the superuser, and the only way to turn it off is via a (hopefully
> > > noticeable) reboot.
> >
> > Interesting. Will this block a user from debugging his own processes?
>
> Yes.
>

Thanks for the tip raf!

> > Perhaps you can plug that hole that way, but that was just the first
> thing
> > that popped in my head. Don't underestimate the creativity of attackers.
> > I for one would not trust my ability to anticipate all possible attacks,
> > and I think that would be a bad security practice.
>
> Yes, but that's no reason not to perform as much risk
> assessment and mitigation as you can afford/justify.
> Not being able to prevent all attacks is no reason not
> to prevent those that you can. :-) Nobody said anything
> about underestimating anyone or trusting anyone.
>

I'm trying to take as layered an approach as possible, aggressively hiding
the key in postgres memory is one approach I'm taking as the out of the box
experience, but I'm also working on AWS KMS integration and a Zymkey HSM
integration. In those cases, keys would be fetched on demand, and
unencrypted keys would only live in memory for a short transaction lifetime
while being used, and then discarded, and I think your ptrace_scope trick
will help add a layer in either case.

-Michel