linux-kernel - Re: [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhS=mMH9s2KUc2kSK7pW1yG8RB58hyJjW5oWsCK=i-1PdA@mail.gmail.com>
Date: Fri, 31 Jan 2025 14:02:49 -0500
From: Paul Moore <paul@...l-moore.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: Christian Brauner <brauner@...nel.org>, Günther Noack <gnoack@...gle.com>, 
	Charles Zaffery <czaffery@...lox.com>, Daniel Burgener <dburgener@...ux.microsoft.com>, 
	Francis Laniel <flaniel@...ux.microsoft.com>, James Morris <jmorris@...ei.org>, 
	Jann Horn <jannh@...gle.com>, Jeff Xu <jeffxu@...gle.com>, Kees Cook <kees@...nel.org>, 
	Luca Boccassi <luca.boccassi@...il.com>, 
	Mikhail Ivanov <ivanov.mikhail1@...wei-partners.com>, 
	Praveen K Paladugu <prapal@...ux.microsoft.com>, Robert Salvet <robert.salvet@...lox.com>, 
	Shervin Oloumi <enlightened@...gle.com>, Tyler Hicks <code@...icks.com>, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH v1 2/3] pidfd: Extend PIDFD_GET_INFO with PIDFD_INFO_LANDLOCK_*_DOMAIN

On Fri, Jan 31, 2025 at 11:43 AM Mickaël Salaün <mic@...ikod.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@...nel.org>
> Cc: Günther Noack <gnoack@...gle.com>
> Cc: Luca Boccassi <luca.boccassi@...il.com>
> Cc: Praveen K Paladugu <prapal@...ux.microsoft.com>
> Closes: https://github.com/landlock-lsm/linux/issues/26
> Signed-off-by: Mickaël Salaün <mic@...ikod.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