[PATCH v2 15/15] landlock: Document the BPF policy interface
From: Justin Suess <hidden>
Date: 2026-08-31 15:01:03
Also in:
bpf, lkml
Subsystem:
documentation, landlock security module, the rest, tracing · Maintainers:
Jonathan Corbet, Mickaël Salaün, Linus Torvalds, Steven Rostedt, Masami Hiramatsu
Describe how the generic LSM policy kfuncs apply to Landlock rulesets: the program-side flow, the staged restriction and its trace event, the LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS semantics on an execution, and why the bprm path carries no no_new_privs/ CAP_SYS_ADMIN precondition. Note the new emission point in the trace events overview. Cc: Mickaël Salaün <mic@digikod.net> Signed-off-by: Justin Suess <redacted> --- Documentation/security/landlock.rst | 38 +++++++++++++++++++++++++ Documentation/trace/events-landlock.rst | 5 +++- 2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/Documentation/security/landlock.rst b/Documentation/security/landlock.rst
index 2d6e1076484e..ddc0d149ae8f 100644
--- a/Documentation/security/landlock.rst
+++ b/Documentation/security/landlock.rst@@ -130,6 +130,44 @@ The reasoning is: restrictions, because access within the same scope is already allowed based on ``LANDLOCK_ACCESS_FS_RESOLVE_UNIX``. +BPF kfuncs +========== + +BPF programs can apply a userspace-created Landlock ruleset to an +execution, through the generic LSM policy kfuncs (see +Documentation/security/lsm-development.rst). A syscall program +(``BPF_PROG_TYPE_SYSCALL``), running in the context of the process +that set the ruleset up, acquires the ruleset with +``bpf_lsm_policy_from_fd()`` and typically hands it over through a +map kptr field; a sleepable LSM BPF program attached to the +``bprm_creds_for_exec`` or ``bprm_creds_from_file`` hooks then +enforces it on an execution with ``bpf_lsm_policy_apply_bprm()``. + +The restriction is staged in the Landlock blob of the credentials +prepared for the execution and committed past the exec point of no +return, so a failed execution leaves the calling task untouched. The +commitment emits the ``landlock_enforce_domain`` trace event (see +Documentation/trace/events-landlock.rst). The kfunc flags take the +``landlock_restrict_self(2)`` flags with their usual semantics, with +the exception of ``LANDLOCK_RESTRICT_SELF_TSYNC``, which is rejected: +the restriction targets the execution, not the calling threads. + +``LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS`` makes the executed program +start with no_new_privs set, binding it and all its descendants. It +does not affect the current execution's privilege computation: the +bprm credentials, including any setuid elevation, are computed before +the flag is set. + +Unlike ``landlock_restrict_self(2)``, the bprm path has no +no_new_privs/``CAP_SYS_ADMIN`` precondition: a task that is not +no_new_privs can carry a BPF-applied domain, and its setuid +executions still elevate while confined. This is sound because +attaching the BPF program is itself privileged, granting the same +power as the syscall's ``CAP_SYS_ADMIN`` carve-out. + +Executions may run concurrently: each takes its own reference on +the shared ruleset with ``bpf_lsm_policy_acquire()``. + Tests =====
diff --git a/Documentation/trace/events-landlock.rst b/Documentation/trace/events-landlock.rst
index af9267cca47d..6cec3194af0b 100644
--- a/Documentation/trace/events-landlock.rst
+++ b/Documentation/trace/events-landlock.rst@@ -34,7 +34,10 @@ Landlock trace events are organized in four categories: - ``landlock_add_rule_fs``: a filesystem rule is added to a ruleset - ``landlock_add_rule_net``: a network port rule is added to a ruleset - ``landlock_create_domain``: a new domain is created from a ruleset -- ``landlock_enforce_domain``: a domain is enforced on a thread +- ``landlock_enforce_domain``: a domain is enforced on a thread. Also + emitted at ``execve(2)``'s point of no return when a BPF program has + staged a policy on the execution (see the BPF kfuncs section of + Documentation/security/landlock.rst) **Denial events** are emitted when an access is denied:
--
2.55.0