Re: RFC: seccomp-bpf support
От | Joshua Brindle |
---|---|
Тема | Re: RFC: seccomp-bpf support |
Дата | |
Msg-id | CAGB+Vh4Jc8rKVLHzFQdJ48uiay4JxPymbTV4k+bjqos5KNi50w@mail.gmail.com обсуждение исходный текст |
Ответ на | RFC: seccomp-bpf support (Joe Conway <mail@joeconway.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: