Re: RFC: seccomp-bpf support - Mailing list pgsql-hackers

From Joshua Brindle
Subject Re: RFC: seccomp-bpf support
Date
Msg-id CAGB+Vh6fB_7xDbtuVfFd_GySY6xs-StK77yfx_6e4uua1pSF9w@mail.gmail.com
Whole thread Raw
In response to Re: RFC: seccomp-bpf support  (Andres Freund <andres@anarazel.de>)
Responses Re: RFC: seccomp-bpf support  (Andres Freund <andres@anarazel.de>)
Re: RFC: seccomp-bpf support  (Thomas Munro <thomas.munro@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: RFC: seccomp-bpf support
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions