Enforce restrictions according to current execution

[l0kod]

For some use cases, we might want to only restrict the current execution but lift these restrictions for the newly executed processes (i.e. calls to execve(2)). The obvious issue of this approach is the ability to "escape" this sandbox (layer) by executing the allowed binaries (if any). However, this approach would be useful to further restrict launchers (e.g. container runtimes, service managers...) without impacting launched programs (that may be unknown to the policy writer). Because Landlock handles nested sandboxes, one could be created for the whole execution environment, and a second one specific to the launcher's execution.

The same way, we could have restrictions that only apply after an execve(2) call.

This is the approach taken by OpenBSD's Pledge (except the ability to create nested sandboxes).

[rata]

Restrictions that apply only after exec are useful for runtimes like runc, too. Specially to offer a landlock policy for the container (the same we do for seccomp).

For example, if we want to start a container with policy to only read in rootfs/etc and some volumes, if we apply that policy we need to be very careful today. We need to do it probably before applying the seccomp policy, as the seccomp policy might block these syscalls, but as close as possible to seccomp too, as otherwise that policy might block access to runc for things we need to do.

If we need to do things in runc after we apply the landlock policy (I'm not sure we need, but it is definitely getting trickier with seccomp and now landlock that want to "run as late as possible"), I think there are other tricks possible (like having a wider landlock policy that allows us to do that, although this has downsides if the container escapes, etc.).

But it will be definitely simpler and less fragile to have a policy for the container if we can say "apply this landlock policy after exec". This is a feature I want for seccomp, for some years now :-D