On Tue, Mar 04, 2025 at 01:13:00AM +0000, Tingmao Wang wrote:
> We allow the user to pass in an additional flag to landlock_create_ruleset
> which will make the ruleset operate in "supervise" mode, with a supervisor
> attached. We create additional space in the landlock_ruleset_attr
> structure to pass the newly created supervisor fd back to user-space.
>
> The intention, while not implemented yet, is that the user-space will read
> events from this fd and write responses back to it.
>
> Note: need to investigate if fd clone on fork() is handled correctly, but
> should be fine if it shares the struct file. We might also want to let the
> user customize the flags on this fd, so that they can request no
> O_CLOEXEC.
>
> NOTE: despite this patch having a new uapi, I'm still very open to e.g.
> re-using fanotify stuff instead (if that makes sense in the end). This is
> just a PoC.
The main security risk of this feature is for this FD to leak and be
used by a sandboxed process to bypass all its restrictions. This should
be highlighted in the UAPI documentation.
>
> Signed-off-by: Tingmao Wang <m@xxxxxxxxxx>
> ---
> include/uapi/linux/landlock.h | 10 ++++
> security/landlock/syscalls.c | 102 +++++++++++++++++++++++++++++-----
> 2 files changed, 98 insertions(+), 14 deletions(-)
>
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index e1d2c27533b4..7bc1eb4859fb 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -50,6 +50,15 @@ struct landlock_ruleset_attr {
> * resources (e.g. IPCs).
> */
> __u64 scoped;
> + /**
> + * @supervisor_fd: Placeholder to store the supervisor file
> + * descriptor when %LANDLOCK_CREATE_RULESET_SUPERVISE is set.
> + */
> + __s32 supervisor_fd;
This interface would require the ruleset_attr becoming updatable by the
kernel, which might be OK in theory but requires current syscall wrapper
signature update, see sandboxer.c change. It also creates a FD which
might not be useful (e.g. if an error occurs before the actual
enforcement).
I see a few alternatives. We could just use/extend the ruleset FD
instead of creating a new one, but because leaking current rulesets is
not currently a security risk, we should be careful to not change that.
Another approach, similar to seccomp unotify, is to get a
"[landlock-domain]" FD returned by the landlock_restrict_self(2) when a
new LANDLOCK_RESTRICT_SELF_DOMAIN_FD flag is set. This FD would be a
reference to the newly created domain, which is more specific than the
ruleset used to created this domain (and that can be used to create
other domains). This domain FD could be used for introspection (i.e.
to get read-only properties such as domain ID), but being able to
directly supervise the referenced domain only with this FD would be a
risk that we should limit.
What we can do is to implement an IOCTL command for such domain FD that
would return a supervisor FD (if the LANDLOCK_RESTRICT_SELF_SUPERVISED
flag was also set). The key point is to check (one time) that the
process calling this IOCTL is not restricted by the related domain (see
the scope helpers).
Relying on IOCTL commands (for all these FD types) instead of read/write
operations should also limit the risk of these FDs being misused through
a confused deputy attack (because such IOCTL command would convey an
explicit intent):
https://docs.kernel.org/security/credentials.html#open-file-credentials
https://lore.kernel.org/all/CAG48ez0HW-nScxn4G5p8UHtYy=T435ZkF3Tb1ARTyyijt_cNEg@xxxxxxxxxxxxxx/
We should get inspiration from seccomp unotify for this too:
https://lore.kernel.org/all/20181209182414.30862-1-tycho@xxxxxxxx/
> + /**
> + * @pad: Unused, must be zero.
> + */
> + __u32 pad;
In this case we should pack the struct instead.
> };
>
> /*
> @@ -60,6 +69,7 @@ struct landlock_ruleset_attr {
> */
> /* clang-format off */
> #define LANDLOCK_CREATE_RULESET_VERSION (1U << 0)
> +#define LANDLOCK_CREATE_RULESET_SUPERVISE (1U << 1)
> /* clang-format on */
>
> /**
[...]
