On 2/17/15 12:50 PM, Stephen Frost wrote:
> Jim,
>
> * Jim Nasby (Jim.Nasby@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