Re: pgaudit - an auditing extension for PostgreSQL

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: pgaudit - an auditing extension for PostgreSQL
Дата
Msg-id 54E38A88.5030607@BlueTreble.com
обсуждение исходный текст
Ответ на Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: pgaudit - an auditing extension for PostgreSQL  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 2/17/15 12:23 PM, Stephen Frost wrote:
> * Jim Nasby (Jim.Nasby@BlueTreble.com) wrote:
>> On 2/17/15 12:07 PM, Stephen Frost wrote:
>>> I agree that it's not the auditing job to stop or control access to
>>> data, but it's not so simple to audit the superuser completely.  The
>>> issue is that even if you have a hard-coded bit in the binary which says
>>> "audit everything", a superuser can change the running code to twiddle
>>> that bit off, redirect the output of whatever auditing is happening,
>>> gain OS-level (eg: shell) access to the system and then make changes to
>>> the files under PG directly, etc.  Setting a bit in a binary and then
>>> not allowing that binary to be unchanged does not actually solve the
>>> issue.
>>
>> If we've allowed a superuser *in the database* that kind of power at
>> the OS level then we have a problem. There needs to be *something*
>> that a database SU can't do at the OS level, otherwise we'll never
>> be able to audit database SU activity.
>
> This isn't a question.  The database superuser has essentially OS-level
> privileges as the user which PG runs as.
>
> I'm all for coming up with a less powerful superuser and the work I've
> been involved in around adding more role attributes is along the lines
> to get us there, but I don't think we're ever going to really reduce the
> power that the PG superuser has, for a variety of reasons.
>
> Improving the documentation of what a superuser can do and how granting
> such access is the same as giving OS shell-level access to the system as
> the user that PG runs as would certainly be good.

It certainly would. I'm honestly not totally clear on what all the holes 
are.

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.

Or maybe there's some other way we could restrict what a DB superuser 
can do in the shell.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: pgaudit - an auditing extension for PostgreSQL
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: pgaudit - an auditing extension for PostgreSQL