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  (Andres Freund <andres@anarazel.de>)
Re: RFC: seccomp-bpf support  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RFC: seccomp-bpf support
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions