landlock: Document LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS

Document setting no_new_privs with ruleset enforcement, following the
same compatibility section style as previous ABI additions.

Include a section explaining the tradeoffs of setting no_new_privs
through any means for privileged users of Landlock.

Signed-off-by: Justin Suess <utilityemal77@gmail.com>
Link: https://patch.msgid.link/20260809154544.1253100-5-utilityemal77@gmail.com
Signed-off-by: Mickaël Salaün <mic@digikod.net>
This commit is contained in:
Justin Suess
2026-08-09 11:45:22 -04:00
committed by Mickaël Salaün
parent 71f98bc6e5
commit f2c55c76bd

View File

@@ -250,7 +250,8 @@ similar backwards compatibility check is needed for the restrict flags
__u32 restrict_flags =
LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
LANDLOCK_RESTRICT_SELF_TSYNC;
LANDLOCK_RESTRICT_SELF_TSYNC |
LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS;
switch (abi) {
case 1 ... 6:
/* Removes logging flags for ABI < 7 */
@@ -269,16 +270,37 @@ similar backwards compatibility check is needed for the restrict flags
* children (and not for all threads, including parents and siblings).
*/
restrict_flags &= ~LANDLOCK_RESTRICT_SELF_TSYNC;
__attribute__((fallthrough));
case 8 ... 10:
/* Removes no new privs flag for ABI < 11 */
restrict_flags &= ~LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS;
}
The next step is to restrict the current thread from gaining more privileges
(e.g. through a SUID binary). We now have a ruleset with the first rule
allowing read and execute access to ``/usr`` while denying all other handled
accesses for the filesystem, and two more rules allowing DNS queries.
(e.g. through a SUID binary). For unprivileged processes, setting the
no_new_privs attribute is required by Landlock.
Processes with ``CAP_SYS_ADMIN`` in their namespace can enforce a ruleset
without setting no_new_privs, but leaving no_new_privs unset is risky even
when Landlock does not require this attribute: sandboxed processes could
still execute set-user-ID, set-group-ID or file-capability binaries, which
would then run with elevated privileges while being restricted by a Landlock
domain they may not expect, making them potential confused deputies.
no_new_privs should only be left unset if such a privilege transition is
expected.
We now have a ruleset with the first rule allowing read and execute access to
``/usr`` while denying all other handled accesses for the filesystem, and two
more rules allowing DNS queries.
.. code-block:: c
if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
/*
* If the ABI > 10, we can tie setting no_new_privs with successful ruleset
* enforcement and skip the manual prctl(PR_SET_NO_NEW_PRIVS, ...) call.
*/
if (!(restrict_flags & LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS) &&
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) {
perror("Failed to restrict privileges");
close(ruleset_fd);
return 1;
@@ -792,6 +814,19 @@ when at least one sys_landlock_add_rule() call is made for it with the
``LANDLOCK_ADD_RULE_QUIET`` flag, additional add-rule calls for the same
object without this flag do not clear it.
no_new_privs flag (ABI < 11)
----------------------------
Starting with the Landlock ABI version 11, sys_landlock_restrict_self()
accepts the ``LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS`` flag, which sets the
no_new_privs attribute of the calling thread only once the enforcement of
the ruleset succeeded: no_new_privs is set if and only if the call
succeeds. This removes the need for a prior :manpage:`prctl(2)`
``PR_SET_NO_NEW_PRIVS`` call (or ``CAP_SYS_ADMIN`` use). When combined
with ``LANDLOCK_RESTRICT_SELF_TSYNC``, no_new_privs is set on all threads
of the process. As explained in the tutorial above, leaving no_new_privs
unset is risky even when Landlock does not require it.
.. _kernel_support:
Kernel support