Re: RFC: seccomp-bpf support
От | Joshua Brindle |
---|---|
Тема | Re: RFC: seccomp-bpf support |
Дата | |
Msg-id | CAGB+Vh6fB_7xDbtuVfFd_GySY6xs-StK77yfx_6e4uua1pSF9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: seccomp-bpf support (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: RFC: seccomp-bpf support
Re: RFC: seccomp-bpf support |
Список | pgsql-hackers |
On Wed, Aug 28, 2019 at 2:53 PM Andres Freund <andres@anarazel.de> wrote: > > Hi, > > On 2019-08-28 14:47:04 -0400, Joshua Brindle wrote: > > 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. > > IIRC it's used by glibc as part of its malloc implementation (also > threading etc) - but not necessarily hit during the most common > paths. That's *precisely* my problem with this approach. > As long as glibc handles a returned error cleanly the syscall could be denied without harming the process and the bug would be mitigated. seccomp also allows argument whitelisting so things can get very granular, depending on who is setting up the lists.
В списке pgsql-hackers по дате отправления: