Re: RFC: seccomp-bpf support
От | Andres Freund |
---|---|
Тема | Re: RFC: seccomp-bpf support |
Дата | |
Msg-id | 20190828192255.g2hv6jt65a5426rl@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: RFC: seccomp-bpf support (Joshua Brindle <joshua.brindle@crunchydata.com>) |
Ответы |
Re: RFC: seccomp-bpf support
|
Список | pgsql-hackers |
Hi, On 2019-08-28 15:02:17 -0400, Joshua Brindle wrote: > On Wed, Aug 28, 2019 at 2:53 PM Andres Freund <andres@anarazel.de> wrote: > > 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. And we'd hit mysterious slowdowns in production uses of PG when seccomp is enabled. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: