From: Tingmao Wang <m@maowtm.org>
To: "Mickaël Salaün" <mic@digikod.net>, "Günther Noack" <gnoack@google.com>
Cc: Christian Brauner <brauner@kernel.org>,
Paul Moore <paul@paul-moore.com>,
"Serge E . Hallyn" <serge@hallyn.com>,
Justin Suess <utilityemal77@gmail.com>,
Lennart Poettering <lennart@poettering.net>,
Mikhail Ivanov <ivanov.mikhail1@huawei-partners.com>,
Nicolas Bouchinet <nicolas.bouchinet@oss.cyber.gouv.fr>,
Shervin Oloumi <enlightened@google.com>,
kernel-team@cloudflare.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [RFC PATCH v1 05/11] landlock: Enforce namespace entry restrictions
Date: Fri, 10 Apr 2026 02:45:16 +0100 [thread overview]
Message-ID: <1d197217-ab74-4caf-abca-7ae35a42fdc0@maowtm.org> (raw)
In-Reply-To: <20260312100444.2609563-6-mic@digikod.net>
On 3/12/26 10:04, Mickaël Salaün wrote:
> [...]
> diff --git a/include/uapi/linux/landlock.h b/include/uapi/linux/landlock.h
> index f88fa1f68b77..b76e656241df 100644
> --- a/include/uapi/linux/landlock.h
> +++ b/include/uapi/linux/landlock.h
> @@ -51,6 +51,14 @@ struct landlock_ruleset_attr {
> * resources (e.g. IPCs).
> */
> __u64 scoped;
> + /**
> + * @handled_perm: Bitmask of permissions (cf. `Permission flags`_)
> + * that this ruleset handles. Each permission controls a broad
> + * operation enforced at a kernel chokepoint: all instances of
> + * that operation are denied unless explicitly allowed by a rule.
> + * See Documentation/security/landlock.rst for the rationale.
> + */
> + __u64 handled_perm;
> };
>
> /**
> @@ -153,6 +161,11 @@ enum landlock_rule_type {
> * landlock_net_port_attr .
> */
> LANDLOCK_RULE_NET_PORT,
> + /**
> + * @LANDLOCK_RULE_NAMESPACE: Type of a &struct
> + * landlock_namespace_attr .
> + */
> + LANDLOCK_RULE_NAMESPACE,
> };
>
> /**
> @@ -206,6 +219,24 @@ struct landlock_net_port_attr {
> __u64 port;
> };
>
> +/**
> + * struct landlock_namespace_attr - Namespace type definition
> + *
> + * Argument of sys_landlock_add_rule() with %LANDLOCK_RULE_NAMESPACE.
> + */
> +struct landlock_namespace_attr {
> + /**
> + * @allowed_perm: Must be set to %LANDLOCK_PERM_NAMESPACE_ENTER.
> + */
> + __u64 allowed_perm;
> + /**
> + * @namespace_types: Bitmask of namespace types (``CLONE_NEW*`` flags)
> + * that should be allowed to be entered under this rule. Unknown bits
> + * are silently ignored for forward compatibility.
> + */
> + __u64 namespace_types;
> +};
> +
> /**
> * DOC: fs_access
> *
This UAPI looks good, follows existing patterns and is extensible.
btw, I guess for consistency, later on this new handled_perm should also
have a quiet_perm, which would allow suppressing audit logs for namespace
/ capability rules (for those (possibly a subset) added with
LANDLOCK_ADD_RULE_QUIET)?
> [...]
> @@ -153,6 +153,48 @@ landlock_get_applicable_subject(const struct cred *const cred,
> return NULL;
> }
>
> +/**
> + * landlock_perm_is_denied - Check if a permission bitmask request is denied
> + *
> + * @domain: The enforced domain.
> + * @perm_bit: The LANDLOCK_PERM_* flag to check.
> + * @request_value: Compact bitmask to look for (e.g. result of
> + * ``landlock_ns_type_to_bit(CLONE_NEWNET)``).
> + *
> + * Iterate from the youngest layer to the oldest. For each layer that
How about this:
/**
* landlock_perm_is_denied - Check if a permission request is denied
*
* @domain: The enforced domain.
* @perm_bit: The LANDLOCK_PERM_* flag to check.
* @request_value: Compact bitmask to look for (e.g. result of
* ``landlock_ns_type_to_bit(CLONE_NEWNET)``).
* Must have only bit set.
*
* Iterate from the youngest layer to the oldest. For each layer that
Basically, to make it more obvious that this functions only checks one
bit. Currently if a combination of permission bits are passed, this
allows access if any of them are allowed, which if accidentally used this
way in the future will probably be a bug. I was considering a
WARN_ON_ONCE but maybe it's a bit unnecessary for now given the caller
always passes a landlock_*_to_bit result (and those already WARN_ON_ONCE
if given invalid parameter).
Reviewed-by: Tingmao Wang <m@maowtm.org>
next prev parent reply other threads:[~2026-04-10 1:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 10:04 [RFC PATCH v1 00/11] Landlock: Namespace and capability control Mickaël Salaün
2026-03-12 10:04 ` [RFC PATCH v1 01/11] security: add LSM blob and hooks for namespaces Mickaël Salaün
2026-03-25 12:31 ` Christian Brauner
2026-04-09 16:40 ` Mickaël Salaün
2026-04-10 9:35 ` Christian Brauner
2026-03-12 10:04 ` [RFC PATCH v1 02/11] security: Add LSM_AUDIT_DATA_NS for namespace audit records Mickaël Salaün
2026-03-25 12:32 ` Christian Brauner
2026-04-01 16:38 ` Mickaël Salaün
2026-04-01 18:48 ` Mickaël Salaün
2026-04-09 13:29 ` Christian Brauner
2026-03-12 10:04 ` [RFC PATCH v1 03/11] nsproxy: Add FOR_EACH_NS_TYPE() X-macro and CLONE_NS_ALL Mickaël Salaün
2026-03-25 12:33 ` Christian Brauner
2026-03-25 15:26 ` Mickaël Salaün
2026-03-26 14:22 ` (subset) " Christian Brauner
2026-03-12 10:04 ` [RFC PATCH v1 04/11] landlock: Wrap per-layer access masks in struct layer_rights Mickaël Salaün
2026-04-10 1:45 ` Tingmao Wang
2026-03-12 10:04 ` [RFC PATCH v1 05/11] landlock: Enforce namespace entry restrictions Mickaël Salaün
2026-04-10 1:45 ` Tingmao Wang [this message]
2026-03-12 10:04 ` [RFC PATCH v1 06/11] landlock: Enforce capability restrictions Mickaël Salaün
2026-03-12 10:04 ` [RFC PATCH v1 07/11] selftests/landlock: Drain stale audit records on init Mickaël Salaün
2026-03-24 13:27 ` Günther Noack
2026-03-12 10:04 ` [RFC PATCH v1 08/11] selftests/landlock: Add namespace restriction tests Mickaël Salaün
2026-03-12 10:04 ` [RFC PATCH v1 09/11] selftests/landlock: Add capability " Mickaël Salaün
2026-03-12 10:04 ` [RFC PATCH v1 10/11] samples/landlock: Add capability and namespace restriction support Mickaël Salaün
2026-03-12 10:04 ` [RFC PATCH v1 11/11] landlock: Add documentation for capability and namespace restrictions Mickaël Salaün
2026-03-12 14:48 ` Justin Suess
2026-03-25 12:34 ` [RFC PATCH v1 00/11] Landlock: Namespace and capability control Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d197217-ab74-4caf-abca-7ae35a42fdc0@maowtm.org \
--to=m@maowtm.org \
--cc=brauner@kernel.org \
--cc=enlightened@google.com \
--cc=gnoack@google.com \
--cc=ivanov.mikhail1@huawei-partners.com \
--cc=kernel-team@cloudflare.com \
--cc=lennart@poettering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=nicolas.bouchinet@oss.cyber.gouv.fr \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=utilityemal77@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox