Implement libseccomp for syscall filtering

[oxr463]

I propose we implement libseccomp and multi-threading simultaneously, (See: seccomp/libseccomp#102).

Originally posted by @oxr463 in #111 (comment)

See: #106, #130

[oxr463]

Excerpts from an email with libseccomp maintainers.

Per Paul,

Hi Lucas,

It looks like proot is trying to ptrace another process, possibly
outside it's sandbox, and is running into problems that you are
attributing to seccomp? Further, it doesn't look like proot itself is
using libseccomp but rather is creating its own seccomp filters.
Without taking a deep dive into proot and its seccomp filters, it is
hard to say what the exact problem may be. Tracing can be difficult
to get right, especially when seccomp filters are involved. I'm not
sure if this is your problem, but the issue that comes to mind first
is the "-1" syscall; see the libseccomp documentation around
SCMP_FLTATR_API_TSKIP for more information on that (manpage can be
seen here -> https://github.com/seccomp/libseccomp/blob/master/doc/man/man3/seccomp_attr_set.3).

FWIW, it also appears that you are not handling a lot of ABI specific
details correctly; for example the x32/x86-64 ABI detection needs
special handling as well as the socket/ipc syscalls on platforms which
support both the multiplexed and direct-wired versions.

My guess is it wouldn't be too difficult, maybe Tom has some experience here? As a
bonus, if you adapted proot to use libseccomp, the ABI problems
mentioned above would be taken care of by the library itself, you
wouldn't need to worry about them in proot.

Per Tom,

I briefly looked through your PRoot code, and while more complex than
the transition I helped work on, at initial glance it doesn't look
too daunting to switch to libseccomp.

Paul brings up several good points of the advantages of using libseccomp
as well. We (libseccomp) will take care of cBPF creation, ABI issues,
and any syscall changes when a new kernel is released. Maintaining a custom
filter throughout all of that can be challenging.

Per Paul,

you will just need to ensure that you have added the
required architecture to the filter, look at the seccomp_arch_add(...)
function/manpage for more information. As long as you add the
architecture before you add the rules, adding a rule to the filter
will add it to the architecture.

If you want to create different rule sets for different architectures
you can create multiple filters, one for each architecture, and merge
them later using the seccomp_merge(...) function. There are some
limitations, e.g. same filter attributes, same endianness, etc., but
in general it works just fine.

In general whilelists tend to be more
restrictive (and potentially "safer" as a result), but they are harder
to maintain. I believe most general purpose container and sandbox
tools currently use a blacklist approach.

[oxr463]

See: https://github.com/proot-me/proot/search?q=seccomp.h&unscoped_q=seccomp.h