Re: RFC: seccomp-bpf support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>
Subject: Re: RFC: seccomp-bpf support
Date: 2019-08-28 18:58:01
Message-ID: 26115.1567018681@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-08-28 14:30:20 -0400, Tom Lane wrote:
>> Admittedly, you can't get per-subprocess restrictions that way, but the
>> incremental value from that seems *really* tiny. If listen() has a bug
>> you need to fix the bug, not invent this amount of rickety infrastructure
>> to limit who can call it.

> And, as I mentioned in another email, once you can corrupt shared memory
> in arbitrary ways, the differing restrictions aren't worth much
> anyway. Postmaster might be separated out enough to survive attacks like
> that, but backends definitely aren't.

Another point in this area is that if you did feel a need for per-process
syscall sets, having a restriction that the postmaster's allowed set be a
superset of all the childrens' allowed sets seems quite the wrong thing.
The set of calls the postmaster needs is probably a lot smaller than what
the children need, seeing that it does so little. It's just different
because it includes bind+listen which the children likely don't need.
So the hierarchical way seccomp goes about this seems fairly wrong for
our purposes regardless.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua Brindle 2019-08-28 19:02:17 Re: RFC: seccomp-bpf support
Previous Message Andres Freund 2019-08-28 18:53:02 Re: RFC: seccomp-bpf support