Re: RFC: seccomp-bpf support

From: Andres Freund <andres(at)anarazel(dot)de>
To: Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>
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:22:55
Message-ID: 20190828192255.g2hv6jt65a5426rl@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message fn ln 2019-08-28 19:29:26 Re: BUG #15977: Inconsistent behavior in chained transactions
Previous Message Tom Lane 2019-08-28 19:19:19 Re: RFC: seccomp-bpf support