| From: | Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: RFC: seccomp-bpf support |
| Date: | 2019-08-28 19:02:17 |
| Message-ID: | CAGB+Vh6fB_7xDbtuVfFd_GySY6xs-StK77yfx_6e4uua1pSF9w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 28, 2019 at 2:53 PM Andres Freund <andres(at)anarazel(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-08-28 19:06:46 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |
| Previous Message | Tom Lane | 2019-08-28 18:58:01 | Re: RFC: seccomp-bpf support |