Re: RFC: seccomp-bpf support

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.

> * 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?

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

Also the other way around?

> * 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?

> 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.

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.

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

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".

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

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services