All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin Suess <utilityemal77@gmail.com>
To: gnoack3000@gmail.com, mic@digikod.net
Cc: linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Justin Suess <utilityemal77@gmail.com>
Subject: [PATCH v3 0/4] Implement LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS
Date: Mon,  3 Aug 2026 18:31:04 -0400	[thread overview]
Message-ID: <20260803223109.707353-1-utilityemal77@gmail.com> (raw)

Howdy

This series adds a new landlock_restrict_self(2) flag:
LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS.

The flag 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 landlock_restrict_self(2) call succeeds.  Following
Mickaël's feedback [2] on v2 [1], the "atomic" framing is gone: this is
an ordering guarantee, not atomicity, and the wording now reflects that
throughout the series.

Semantics:

A single call replaces the usual prctl(PR_SET_NO_NEW_PRIVS) +
landlock_restrict_self(2) pair.  Because no_new_privs is set by the
call itself, the no_new_privs/CAP_SYS_ADMIN precondition is fulfilled
by construction, so the flag is usable by unprivileged processes.  This
is safe for the same reason the prctl(2) pair is: the executed programs
can either gain privileges or be restricted, never both.

The two states cannot diverge.  A failed call (invalid ruleset FD,
E2BIG, ENOMEM, interrupted TSYNC, ...) leaves no_new_privs unchanged,
and a successful call never returns without no_new_privs set: the
attribute is set past the last point of failure, right before
commit_creds(), which cannot fail.

Combined with LANDLOCK_RESTRICT_SELF_TSYNC, no_new_privs is set on all
threads with the same guarantee: each sibling thread sets it in the
commit phase of the TSYNC protocol, after its all-or-nothing barrier,
so either every thread gets both the domain and no_new_privs, or none
does.  This also makes it possible to set no_new_privs process-wide in
one call, which prctl(2) cannot do.

The flag requires a ruleset: calls with a ruleset_fd of -1 are
rejected.  Such a call would be nothing more than a Landlock-flavored
prctl(PR_SET_NO_NEW_PRIVS), and rejecting it keeps the option of giving
it a meaning later.  As a consequence of the fulfilled precondition, an
unprivileged caller passing unknown flag bits together with this flag
receives EINVAL instead of EPERM; the selftests pin this error ordering
as well.

The Landlock ABI version is bumped to 11.

Test coverage:

base_test checks that a successful call sets no_new_privs without a
prior prctl(2) nor CAP_SYS_ADMIN, that a failed call (invalid ruleset
FD or layer maximum) leaves it unchanged, that the flag requires a
ruleset FD, and the updated EPERM/EINVAL ordering.  tsync_test checks
that TSYNC sets no_new_privs on sibling threads along with the domain,
and that a TSYNC call failing on the layer maximum leaves it unset on
every thread.

Changes since v2:

- Reworded "atomically" to the ordering guarantee in the commit
  messages, kdocs and documentation, per Mickaël's feedback.
- Explained the valid-ruleset requirement in the first patch's commit
  message.
- Ran clang-format on the selftests and added max-layers failure tests
  checking E2BIG and that no_new_privs stays unset.
- Mentioned the selftest renames in the commit message.
- Updated the documentation tutorial (restrict_flags gated on the ABI
  version, prctl(2) call skipped when the flag is used) and explained
  that not setting no_new_privs is risky even when it is not required.
- New patch: the sandboxer sample now uses the flag by default, gated
  on the ABI version, with a prctl(2) fallback.

Per-patch changelogs are below each patch.

[1] https://lore.kernel.org/linux-security-module/20260717220320.1030123-1-utilityemal77@gmail.com/
[2] https://lore.kernel.org/linux-security-module/20260731.at2Zilei1ech@digikod.net/

Justin Suess (4):
  landlock: Add LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS
  selftests/landlock: Test LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS
  landlock: Document LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS
  samples/landlock: Add LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS to sampler

 Documentation/userspace-api/landlock.rst      | 47 +++++++--
 include/uapi/linux/landlock.h                 | 13 +++
 samples/landlock/sandboxer.c                  | 16 ++-
 security/landlock/limits.h                    |  2 +-
 security/landlock/syscalls.c                  | 28 ++++--
 security/landlock/tsync.c                     |  8 +-
 security/landlock/tsync.h                     |  4 +-
 tools/testing/selftests/landlock/base_test.c  | 99 ++++++++++++++++++-
 tools/testing/selftests/landlock/tsync_test.c | 72 ++++++++++++++
 9 files changed, 263 insertions(+), 26 deletions(-)


base-commit: 308bc78f1e577439ca61ec77842a5a3ba7e8bbce
-- 
2.54.0


             reply	other threads:[~2026-08-03 22:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 22:31 Justin Suess [this message]
2026-08-03 22:31 ` [PATCH v3 1/4] landlock: Add LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS Justin Suess
2026-08-07 10:51   ` Mickaël Salaün
2026-08-07 13:18   ` Mickaël Salaün
2026-08-09 15:31     ` Justin Suess
2026-08-11  7:16       ` Mickaël Salaün
2026-08-03 22:31 ` [PATCH v3 2/4] selftests/landlock: Test LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS Justin Suess
2026-08-07 10:48   ` Mickaël Salaün
2026-08-03 22:31 ` [PATCH v3 3/4] landlock: Document LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS Justin Suess
2026-08-07 10:57   ` Mickaël Salaün
2026-08-03 22:31 ` [PATCH v3 4/4] samples/landlock: Add LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS to sampler Justin Suess

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=20260803223109.707353-1-utilityemal77@gmail.com \
    --to=utilityemal77@gmail.com \
    --cc=gnoack3000@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.