On Wed, Aug 28, 2019 at 2:47 PM Joshua Brindle <joshua.brin...@crunchydata.com> wrote: > > 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,
And I forgot the citations *sigh*, actually there should have only been [1]: 1. https://commitfest.postgresql.org/24/2259/ > 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.
