Re: Hardening PostgreSQL via (optional) ban on local file system access - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Hardening PostgreSQL via (optional) ban on local file system access
Date
Msg-id CAMT0RQTd7b0ZNguJ3samN252UczEO3D2Jphy2v4DMQ=Qc0hz8g@mail.gmail.com
Whole thread Raw
In response to Re: Hardening PostgreSQL via (optional) ban on local file system access  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Hardening PostgreSQL via (optional) ban on local file system access
List pgsql-hackers
What are your ideas of applying a change similar to above to actually
being a superuser ?

That is adding a check for "superuser being currently available" to
function superuser() in
./src/backend/utils/misc/superuser.c ?

It could be as simple as a flag that can be set only at startup for
maximum speed - though the places needing superuser check are never in
speed-critical path as far as I have seen.

Or it could be more complex and dynamix, like having a file similar to
pg_hba.conf that defines the ability to run code as superuser based on
a set of attributes each of which could be * meaning "any"

These could be
  * database (to limit superuser to only certain databases)
  * session user (to allow only some users to become superuser,
including via SECURITY DEFINER functions)
  * backend pid (this would allow kind of 2-factor authentication -
connect, then use that session's pid to add a row to
pg_ok_to_be_sup.conf file, then continue with your superuser-y stuff)
  * valid-until - this lets one allow superuser for a limited period
without fear of forgetting top disable it

This approach would have the the benefit of being very low-code while
delivering the extra protection of needing pre-existing access to
filesystem to enable/disable .

For easiest usability the pg_ok_to_be_sup.conf file should be outside
pg_reload_conf() - either just read each time the superuser() check is
run, or watched via inotify and reloaded each time it changes.

Cheers,
Hannu

P.S: - thanks Magnus for the "please don't top-post" notice - I also
need to remember to check if all the quoted mail history is left in
when I just write a replay without touching any of it. I hope it does
the right thing and leaves it out, but it just might unders some
conditions bluntly append it anyway just in case :)



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Amcheck verification of GiST and GIN
Next
From: Hannu Krosing
Date:
Subject: Re: Hardening PostgreSQL via (optional) ban on local file system access