On 2/17/15 12:50 PM, Stephen Frost wrote:
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
We may need to bite the bullet and allow changing the user that the
postgres process runs under so it doesn't match who owns the files.
Maybe there's a way to allow that other than having the process
start as root.
That's an interesting thought but it doesn't seem too likely to work out
for us. The process still has to be able to read and write the files,
create new files in the PGDATA directories, etc.
Right, but if we don't allow things like loading C functions from
wherever you please then it's a lot less likely that a DB SU could
disable auditing.
Or maybe there's some other way we could restrict what a DB
superuser can do in the shell.
This could be done with SELinux and similar tools, but at the end of the
day the answer, in my view really, is to have fewer superusers and for
those superusers to be understood to have OS-level shell access. We
don't want to deal with all of the security implications of trying to
provide a "trusted" superuser when that user can create functions in
untrusted languages, modify the catalog directly, etc, it really just
doesn't make sense.
The part I don't like about that is then you still have this highly
trusted account that can also run SQL. The big issue with that is that
no OS-level auditing is going to catch what happens inside the database
itself (well, I guess short of a key logger...)
What I'd prefer to see is a way to decouple the OS account from any DB
account. Clearly that doesn't protect us from the OS user doing
something bad, but at least then there's no way for them to just
silently run SQL commands.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers