Re: RFC: seccomp-bpf support

On 8/28/19 1:03 PM, Peter Eisentraut wrote:
> On 2019-08-28 17:13, Joe Conway wrote:
>> * systemd does not implement seccomp filters by default. Packagers may
>> decide to do so, but there is no guarantee. Adding them post install
>> potentially requires cooperation by groups outside control of
>> the database admins.
>
> Well, if we are interested in this, why don't we just ask packagers to
> do so? That seems like a much easier solution.

For the reason listed below

>> * In the container and systemd case there is no particularly good way to
>> inspect what filters are active. It is possible to observe actions
>> taken, but again, control is possibly outside the database admin
>> group. For example, the best way to understand what happened is to
>> review the auditd log, which is likely not readable by the DBA.
>
> Why does one need to know what filters are active (other than,
> obviously, checking that the filters one has set were actually
> activated)? What decisions would a DBA or database user be able to make
> based on whether a filter is set or not?

So that when an enforement action happens, you can understand why it
happened. Perhaps it was a bug (omission) in your allow list, or perhaps
it was an intentional rule to prevent abuse (say blocking certain
syscalls from plperlu), or it was because someone is trying to
compromise you system (e.g. some obscure and clearly not needed syscall).

>> * With built-in support, it is possible to lock down backend processes
>> more tightly than the postmaster.
>
> Also the other way around?

As I stated in the original email, the filters can add restrictions but
never remove them.

>> * With built-in support, it is possible to lock down different backend
>> processes differently than each other, for example by using ALTER ROLE
>> ... SET or ALTER DATABASE ... SET.
>
> What are use cases for this?

For example to allow a specific user to use plperlu to exec shell code
while others cannot.

>> Attached is a patch for discussion, adding support for seccomp-bpf
>> (nowadays generally just called seccomp) syscall filtering at
>> configure-time using libseccomp. I would like to get this in shape to be
>> committed by the end of the November CF if possible.
>
> To compute the initial set of allowed system calls, you need to have
> fantastic test coverage. What you don't want is some rarely used error
> recovery path to cause a system crash. I wouldn't trust our current
> coverage for this.

So if you are worried about that make your default action 'log' and
watch audit.log. There will be no errors or crashes of postgres caused
by that because there will be no change in postgres visible behavior.

And if returning an error from a syscall causes a crash that would be a
serious bug and we should fix it.

> Also, the list of system calls in use changes all the time. The same
> function call from PostgreSQL could be a system call or a glibc
> implementation, depending on the specific installed packages or run-time
> settings.

True. That is why I did not provide an initial list and believe folks
who want to use this should develop their own.

> Extensions would need to maintain their own permissions list, and they
> would need to be merged manually into the respective existing settings.

People would have to generate their own list for extensions -- I don't
believe it is the extension writers' problem.

> Without good answers to these, I suspect that this feature would go
> straight to the top of the list of "if in doubt, turn off".

That is fine. Perhaps most people never use this, but when needed (and
increasingly will be required) it is available.

> Overall, I think this sounds like a maintenance headache, and the
> possible benefits are unclear.

The only people who will incur the maintenance headache are those who
need to use it. The benefits are compliance with requirements.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development