Among other differences, pledge() from OpenBSD takes a string
and has exec promises. We don't.
Using the same name yet providing a different interface does not
appear reasonable.
We cannot assume that landlock is enabled if we can compile it.
Even if it's enabled in the kernel it may still not be loaded.
We fill fallback to chroot/bind-mounts if we can.
If we can't (because path policies have landlock-specific options),
we can't do that either.
Closes: #21
Some distros put sys/capability.h into libcap-dev or
similiar, which is a bit unforunate, we don't need
libcap-dev or anything like that.
Since we anyway only used the capget()/capset(), we can
just define a simple wrapper and call the syscall directly
and therefore avoid above mentioned issue.
This begins a pledge() implementation. This also
retires the previous syscall grouping approach,
as pledge() is the superior mechanism.
Squashed:
test: Begin basic pledge test
pledge: Begin EXILE_SYSCALL_PLEDGE_UNIX/EXILE_SYSCALL_PLEDGE_INET
test: Add pledge socket test
Introduce EXILE_SYSCALL_PLEDGE_DENY_ERROR, remove exile_policy->pledge_policy
pledge: Add PROT_EXEC
Squashed:
test: Adjust existing to new API with arg filters
test: Add tests for low-level seccomp args filter API
test: Add seccomp_filter_mixed()
test: Switch to syscall() everywhere
append_syscall_to_bpf(): Apply EXILE_SYSCALL_EXIT_BPF_NO_MATCH also for sock_filter.jt
qssb.h was a preliminary name and can't be pronounced smoothly.
exile.h is more fitting and it's also short. Something exiled is essentially
something isolated, which is pretty much what this library does (isolation from
resources such as file system, network and others accessible by system calls).
Cannot be done properly on a pure syscall basis at this point.
A whitelist is almost certainly too restrictive, which means user
has to manually adjust the policy anyway. Then the default is not
of much use. Or too permissive.
A blacklist has to play catchup with new kernel versions. This may
be be improved upon by blocking all unknown (too new) syscall
numbers. However, in light of the fact we drop caps and set no_new_privs,
it's debtable how much we can gain from a blacklist anyway.
So best to leave it to the user. We also need to allow checking args
too in order to make it easier to build policies. Perhaps get
inspiration from pledge() in OpenBSD.
Classify syscalls into groups, for x86_64 only for now.
Up to date for 5.15, generate some #ifndef for syscalls
introduced since 5.10. Only support x86_64 therefore at this point.
Switch from blacklisting to a default whitelist.
Refactor the test logic. Seccomp tests that can be
killed run in their own subprocess now.
All test functions now return 0 on success. Therefore,
the shell script can be simplified.
Instead of having a blacklist and whitelist, we now allow
setting a policy that runs as a chain.
This adds qssb_append_syscalls_policy()
Furthermore, add a feature to decide per syscall which action to take.
This allows now to return an error instead of just killing the process.
In the future, it may allow us to set optimize/shrink the BPF filter.
The arch field is the same for x86_64 and x32, thus checking it
is not enough.
Simply using x32 system calls would allow a bypass. Thus,
we must check whether the system call number is in __X32_SYSCALL_BIT.
This is of course a lazy solution, we could also add the
same system call number + _X32_SYSCALL_BIT to our black/whitelists.
For now however, this however will do.
The filter was missing this check for arch, allowing bypasses
by using different calling conventions of other architectures.
A trivial example is execve() of x86 from and x86_64 process.
The purpose of these new functions is to make it simpler for users
to add new syscalls to the whitelist and blacklist.
The current approach uses a user-supplied pointer which however
was difficult to manage with "no_fs", which may add systemcalls
to the blacklist. Then we must resize arrays, and suddenly
it's our job to free them.
As a bonus, implementing them here allows easier data structure
changes and decreases the chances tgat users of this API
do something wrong, like forgetting -1 at then end, etc.
