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
