On Wed, Aug 28, 2019 at 2:30 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > <snip> > > (And, TBH, I'm still wondering why SELinux isn't the way to address this.)
Just going to address this one now. SELinux is an LSM and therefore only makes decisions when LSM hooks are invoked, which are not 1:1 for syscalls (not even close). Further, SELinux generally determines what objects a subject can access and only implements capabilities because it has to, to be non-bypassable. Seccomp filtering is an orthogonal system to SELinux and LSMs in general. We are already doing work to further restrict PG subprocesses with SELinux via [1] and [2], but that doesn't address the unused, high-risk, obsolete, etc syscall issue. A prime example is madvise() which was a catastrophic failure that 1) isn't preventable by any LSM including SELinux, 2) isn't used by PG and is therefore a good candidate for a kill list, and 3) a clear win in the dont-let-PG-be-a-vector-for-kernel-compromise arena. We are using SELinux, we are also going to use this, they work together.
