[RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN

[Paul Moore]

On Fri, Jan 31, 2025 at 11:43 AM Mickaël Salaün <mic at digikod.net> wrote:
>
> Because Landlock enables users to create nested sandboxes (i.e.
> domains), we might need to identify the domain with all restrictions
> (latest), or the domain we created (i.e. closest domain).  Indeed,
> because any process can create its own domain, the latest domain may not
> be known by the requester.
>
> The PIDFD_INFO_LANDLOCK_LAST_DOMAIN flag enables user space to get the
> latest (i.e. most nested) Landlock domain ID related to a sandboxed
> task, if any.  The domain ID is set in the pidfd_info's
> landlock_last_domain field according to the related mask.
>
> The PIDFD_INFO_LANDLOCK_FIRST_DOMAIN flag enables user space to get the
> closest (i.e. first hierarchy relative to the pidfd's credentials)
> Landlock domain ID related to a sandboxed task, if any.  The domain ID
> is set in the pidfd_info's landlock_first_domain field according to the
> related mask.
>
> It is only allowed to get information about a Landlock domain if the
> task's domain that created the pidfd is a parent of the PID's domain.
> Following the object-capability model, the pidfd's credentials are used
> instead of the caller's credentials.  This makes this command
> idenmpotent wrt the referenced process's state.
>
> If Landlock is not supported or if access to this information is denied,
> then the IOCTL does not set the PIDFD_INFO_LANDLOCK_*_DOMAIN flag in the
> returned mask.
>
> If PIDFD_INFO_LANDLOCK_LAST_DOMAIN or PIDFD_INFO_LANDLOCK_FIRST_DOMAIN
> is specified but the provided struct pidfd_info is not large enough to
> contain the related field, then -EINVAL is returned.
>
> Cc: Christian Brauner <brauner at kernel.org>
> Cc: Günther Noack <gnoack at google.com>
> Cc: Luca Boccassi <luca.boccassi at gmail.com>
> Cc: Praveen K Paladugu <prapal at linux.microsoft.com>
> Closes: https://github.com/landlock-lsm/linux/issues/26
> Signed-off-by: Mickaël Salaün <mic at digikod.net>
> Link: https://lore.kernel.org/r/20250131163447.1140564-3-mic@digikod.net
> ---
>  fs/pidfs.c                 | 24 ++++++++++++++++++++++--
>  include/uapi/linux/pidfd.h |  4 ++++
>  2 files changed, 26 insertions(+), 2 deletions(-)

While there are exceptions, mostly for legacy things, we try very hard
to avoid having the kernel call directly into a specific LSM,
preferring to use LSM interfaces, both so that all LSMs can benefit
from the change and also so that we can avoid having a lot of very
similar, but LSM-specific, calls in various parts in the kernel.

There is an effort, albeit a slowly moving effort due to interrupts,
to add LSM support via a PIDFS_GET_SECURITY API:

https://lore.kernel.org/linux-security-module/CAHC9VhRV3KcNGRw6_c-97G6w=HKNuEQoUGrfKhsQdWywzDDnBQ@mail.gmail.com/

I don't see any reason why we couldn't support Landlock's domain info
as part of that, the lsm_ctx struct was created to support various
different LSM contexts/attributes.  You could either add multiple
lsm_ctx array entries for Landlock, one for each of the domain IDs, or
you could place all of the domain IDs in an expanded lsm_ctx.
Remember the lsm_ctx->ctx field can hold binary blobs and/or you can
expand past the end of lsm_ctx->ctx so long as lsm_ctx->{len,ctx_len}
are set accordingly.

If you want to work on the PIDFS_GET_SECURITY patch(set) as a means to
add Landlock domain ID support, I think that would be great.  Luca
provided a basic skeleton in the link above, and I expect you would
have no issue adding the missing LSM bits.

-- 
paul-moore.com