On Thu, Aug 29, 2019 at 7:08 AM Joshua Brindle <joshua.brin...@crunchydata.com> wrote: > On Wed, Aug 28, 2019 at 2:53 PM Andres Freund <and...@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%2BhUKGLiR569VHLjtCNp3NT%2BjnKdhy8g2sdgKzWNojyWQVt6Bw%40mail.gmail.com -- Thomas Munro https://enterprisedb.com
