Thread: Hiding a GUC from SQL

Michel Pelletier <pelletier.michel@gmail.com> writes:
> In my extension pgsodium I'm defining a custom variable at startup to store
> a key:

> https://github.com/michelp/pgsodium/blob/master/src/pgsodium.c#L1107

> I'm using the flags GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE
> | GUC_DISALLOW_IN_FILE, and a custom "no show" show hook that obscures the
> value.  This idea was inspired from the pgcryptokey module from Bruce
> Momjian.

I guess I'm wondering why you're making it a GUC at all, if you don't
want any of the GUC facilities to apply.

As far as I can think at the moment, putting in a no-op show hook
is sufficient to prevent the value from being seen at the SQL level.
However, it's far from clear that doing that isn't going to have
negative side-effects; it'll possibly also break other things like
GUC save/restore (eg rolling back when a transaction fails).

It seems like if you want to be this paranoid, you'd be better off
not exposing the variable to the GUC machinery in the first place.
You could use a custom set-function (like setseed) to replace the one
bit of functionality you do want.

            regards, tom lane

On Wed, 2020-06-17 at 13:23 -0700, Michel Pelletier wrote:
> In my extension pgsodium I'm defining a custom variable at startup to store a key:
> 
> https://github.com/michelp/pgsodium/blob/master/src/pgsodium.c#L1107
> 
> I'm using the flags GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE,
> and a custom "no show" show hook that obscures the value.  This idea was inspired from the
> pgcryptokey module from Bruce Momjian.
> 
> The value cannot be shown either with SHOW or current_setting() and it does not appear in pg_settings.
>  From what I can tell, the value is inaccessible from SQL, but I think it's worth asking
> the experts if there is some other demonstrable way, from SQL, that this value could be
> leaked even to a superuser.  no sql level user should be able to see this value, only a C function,
> like the pgsodium_derive() from which to derive other keys, should be able to see it.
> I realize that someone with external process access can get the key, my  goal is to prevent
> accessing it from SQL.
> 
> Any thoughts on weaknesses to this approach would be welcome.  Thanks!
> 
> -Michel

A superuser can access files and start programs on the server machine.

A dedicated superuser may for example attach to PostgreSQL with a debugger
and read the value of the variable.

And if that doesn't work, there may be other things to try.

It is mostly useless to try to keep a superuser from doing anything that
the "postgres" operating system user can do.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com

Laurenz Albe wrote:

> On Wed, 2020-06-17 at 13:23 -0700, Michel Pelletier wrote:
> > In my extension pgsodium I'm defining a custom variable at startup to store a key:
> > 
> > https://github.com/michelp/pgsodium/blob/master/src/pgsodium.c#L1107
> > 
> > I'm using the flags GUC_NO_SHOW_ALL | GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE,
> > and a custom "no show" show hook that obscures the value.  This idea was inspired from the
> > pgcryptokey module from Bruce Momjian.
> > 
> > The value cannot be shown either with SHOW or current_setting() and it does not appear in pg_settings.
> >  From what I can tell, the value is inaccessible from SQL, but I think it's worth asking
> > the experts if there is some other demonstrable way, from SQL, that this value could be
> > leaked even to a superuser.  no sql level user should be able to see this value, only a C function,
> > like the pgsodium_derive() from which to derive other keys, should be able to see it.
> > I realize that someone with external process access can get the key, my  goal is to prevent
> > accessing it from SQL.
> > 
> > Any thoughts on weaknesses to this approach would be welcome.  Thanks!
> > 
> > -Michel
> 
> A superuser can access files and start programs on the server machine.
> 
> A dedicated superuser may for example attach to PostgreSQL with a debugger
> and read the value of the variable.
> 
> And if that doesn't work, there may be other things to try.
> 
> It is mostly useless to try to keep a superuser from doing anything that
> the "postgres" operating system user can do.
> 
> Yours,
> Laurenz Albe

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. And, if the keys aren't present on the server at
boot time, and aren't fetched from their remote source (or read from a
user) unless that yama setting is in place, then it will be very hard
for a superuser to obtain the keys. If a remote source KMS is used,
ideally, you'd also want it to cryptographically verify that its client
hadn't been tampered with (somehow), or to not hand out the keys except
for planned reboots. The point is that it's not useless to make things
harder for a superuser.

You might not stop a legitimate sitewide superuser whose family is being
held hostage, but you can stop, or at least make things much more
difficult, for a superuser process on a single host that is the result
of a software vulnerability that wasn't nobbled by apparmor or selinux
or grsecurity.

cheers,
raf

On Mon, 2020-06-22 at 09:44 +1000, raf wrote:
> A superuser can access files and start programs on the server machine.
> > A dedicated superuser may for example attach to PostgreSQL with a debugger
> > and read the value of the variable.
> > 
> > And if that doesn't work, there may be other things to try.
> > 
> > It is mostly useless to try to keep a superuser from doing anything that
> > the "postgres" operating system user can do.
> 
> 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?
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.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com

Laurenz Albe wrote:

> On Mon, 2020-06-22 at 09:44 +1000, raf wrote:
> > A superuser can access files and start programs on the server machine.
> > > A dedicated superuser may for example attach to PostgreSQL with a debugger
> > > and read the value of the variable.
> > > 
> > > And if that doesn't work, there may be other things to try.
> > > 
> > > It is mostly useless to try to keep a superuser from doing anything that
> > > the "postgres" operating system user can do.
> > 
> > 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.

> 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.

> Yours,
> Laurenz Albe

cheers,
raf