| From: |
| Thomas Munro <thomas.munro-AT-gmail.com> |
| To: |
| Joshua Brindle <joshua.brindle-AT-crunchydata.com> |
| Subject: |
| Re: RFC: seccomp-bpf support |
| Date: |
| Thu, 29 Aug 2019 07:47:35 +1200 |
| Message-ID: |
| <CA+hUKG+bgvR2_2mD6LSyEFPDqFeqPuYi6ecBb0zr5odofiNTYA@mail.gmail.com> |
| Cc: |
| Andres Freund <andres-AT-anarazel.de>, Tom Lane <tgl-AT-sss.pgh.pa.us>, Joe Conway <mail-AT-joeconway.com>, PostgreSQL-development <pgsql-hackers-AT-postgresql.org> |
| Archive-link: |
| Article |
On Thu, Aug 29, 2019 at 7:08 AM Joshua Brindle
<joshua.brindle@crunchydata.com> wrote:
> On Wed, Aug 28, 2019 at 2:53 PM Andres Freund <andres@anarazel.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.
>
> seccomp also allows argument whitelisting so things can get very
> granular, depending on who is setting up the lists.
Just by the way, there may also be differences between architectures.
After some head scratching, we recently discovered[1] that default
seccomp whitelists currently cause PostgreSQL to panic for users of
Docker, Nspawn etc on POWER and ARM because of that. That's a bug
being fixed elsewhere, but it reveals another thing to be careful of
if you're trying to build your own whitelist by guessing what libc
needs to call.
[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKGLiR56...
--
Thomas Munro
https://enterprisedb.com
