Re: RFC: seccomp-bpf support

On Wed, Aug 28, 2019 at 1:42 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > On 2019-08-28 17:13, Joe Conway wrote:
> >> Attached is a patch for discussion, adding support for seccomp-bpf
> >> (nowadays generally just called seccomp) syscall filtering at
> >> configure-time using libseccomp. I would like to get this in shape to be
> >> committed by the end of the November CF if possible.
>
> > To compute the initial set of allowed system calls, you need to have
> > fantastic test coverage.  What you don't want is some rarely used error
> > recovery path to cause a system crash.  I wouldn't trust our current
> > coverage for this.
>
> Yeah, that seems like quite a serious problem.  I think you'd want
> to have some sort of static-code-analysis-based way of identifying
> the syscalls in use, rather than trying to test your way to it.
>
> > Overall, I think this sounds like a maintenance headache, and the
> > possible benefits are unclear.
>
> After thinking about this for awhile, I really don't follow what
> threat model it's trying to protect against.  Given that we'll allow
> any syscall that an unmodified PG executable might use, it seems
> like the only scenarios being protected against involve someone
> having already compromised the server enough to have arbitrary code
> execution.  OK, fine, but then why wouldn't the attacker just
> bypass libseccomp?  Or tell it to let through the syscall he wants
> to use?  Having the list of allowed syscalls be determined inside
> the process seems like fundamentally the wrong implementation.
> I'd have expected a feature like this to be implemented by SELinux,

SELinux is generally an object model and while it does implement e.g.,
capability checks, that is not the main intent, nor is it possible for
LSMs to implement syscall filters, the features are orthogonal.

> or some similar technology where the filtering is done by logic
> that's outside the executable you wish to not trust.
> (After googling for libseccomp, I see that it's supposed to not
> allow syscalls to be turned back on once turned off, but that isn't
> any protection against this problem.  An attacker who's found an ACE
> hole in Postgres can just issue ALTER SYSTEM SET to disable the
> feature, then force a postmaster restart, then profit.)
>

My preference would have been to enable it unconditionally but Joe was
being more practical.

> I follow the idea of limiting the attack surface for kernel bugs,
> but this doesn't seem like a useful implementation of that, even
> ignoring the ease-of-use problems Peter mentions.

Limiting the kernel attack surface for network facing daemons is
imperative to hardening systems. All modern attacks are chained
together so a kernel bug is useful only if you can execute code, and
PG is a decent vector for executing code.

At a minimum I would urge the community to look at adding high risk
syscalls to the kill list, systemd has some predefined sets we can
pick from like @obsoluete, @cpu-emulation, @privileged, @mount, and
@module.

The goal is to prevent an ACE hole in Postgres from becoming a
complete system compromise. This may not do it alone, and security
conscious integrators will want to, for example, add seccomp filters
to systemd to prevent superuser from disabling them. The postmaster
and per-role lists can further reduce the available syscalls based on
the exact extensions and PLs being used. Each step reduced the surface
more and throwing it all out because one step can go rogue is
unsatisfying.

Thank you.