On Wed, Aug 28, 2019 at 2:47 PM Joshua Brindle
<joshua.brindle@crunchydata.com> wrote:
>
> On Wed, Aug 28, 2019 at 2:30 PM Tom Lane <tgl@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.