linux.git/security/security.c, branch v7.1-rc2

Merge tag 'landlock-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux

2026-04-13T22:42:19+00:00

Pull Landlock update from Mickaël Salaün:
 "This adds a new Landlock access right for pathname UNIX domain sockets
  thanks to a new LSM hook, and a few fixes"

* tag 'landlock-7.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux: (23 commits)
  landlock: Document fallocate(2) as another truncation corner case
  landlock: Document FS access right for pathname UNIX sockets
  selftests/landlock: Simplify ruleset creation and enforcement in fs_test
  selftests/landlock: Check that coredump sockets stay unrestricted
  selftests/landlock: Audit test for LANDLOCK_ACCESS_FS_RESOLVE_UNIX
  selftests/landlock: Test LANDLOCK_ACCESS_FS_RESOLVE_UNIX
  selftests/landlock: Replace access_fs_16 with ACCESS_ALL in fs_test
  samples/landlock: Add support for named UNIX domain socket restrictions
  landlock: Clarify BUILD_BUG_ON check in scoping logic
  landlock: Control pathname UNIX domain socket resolution by path
  landlock: Use mem_is_zero() in is_layer_masks_allowed()
  lsm: Add LSM hook security_unix_find
  landlock: Fix kernel-doc warning for pointer-to-array parameters
  landlock: Fix formatting in tsync.c
  landlock: Improve kernel-doc "Return:" section consistency
  landlock: Add missing kernel-doc "Return:" sections
  selftests/landlock: Fix format warning for __u64 in net_test
  selftests/landlock: Skip stale records in audit_match_record()
  selftests/landlock: Drain stale audit records on init
  selftests/landlock: Fix socket file descriptor leaks in audit helpers
  ...

Merge tag 'lsm-pr-20260410' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm

2026-04-13T22:17:28+00:00

Pull LSM updates from Paul Moore:
 "We only have five patches in the LSM tree, but three of the five are
  for an important bugfix relating to overlayfs and the mmap() and
  mprotect() access controls for LSMs. Highlights below:

   - Fix problems with the mmap() and mprotect() LSM hooks on overlayfs

     As we are dealing with problems both in mmap() and mprotect() there
     are essentially two components to this fix, spread across three
     patches with all marked for stable.

     The simplest portion of the fix is the creation of a new LSM hook,
     security_mmap_backing_file(), that is used to enforce LSM mmap()
     access controls on backing files in the stacked/overlayfs case. The
     existing security_mmap_file() does not have visibility past the
     user file. You can see from the associated SELinux hook callback
     the code is fairly straightforward.

     The mprotect() fix is a bit more complicated as there is no way in
     the mprotect() code path to inspect both the user and backing
     files, and bolting on a second file reference to vm_area_struct
     wasn't really an option.

     The solution taken here adds a LSM security blob and associated
     hooks to the backing_file struct that LSMs can use to capture and
     store relevant information from the user file. While the necessary
     SELinux information is relatively small, a single u32, I expect
     other LSMs to require more than that, and a dedicated backing_file
     LSM blob provides a storage mechanism without negatively impacting
     other filesystems.

     I want to note that other LSMs beyond SELinux have been involved in
     the discussion of the fixes presented here and they are working on
     their own related changes using these new hooks, but due to other
     issues those patches will be coming at a later date.

   - Use kstrdup_const()/kfree_const() for securityfs symlink targets

   - Resolve a handful of kernel-doc warnings in cred.h"

* tag 'lsm-pr-20260410' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm:
  selinux: fix overlayfs mmap() and mprotect() access checks
  lsm: add backing_file LSM hooks
  fs: prepare for adding LSM blob to backing_file
  securityfs: use kstrdup_const() to manage symlink targets
  cred: fix kernel-doc warnings in cred.h

lsm: Add LSM hook security_unix_find

2026-04-07T16:51:05+00:00

Add an LSM hook security_unix_find.

This hook is called to check the path of a named UNIX socket before a
connection is initiated. The peer socket may be inspected as well.

Why existing hooks are unsuitable:

Existing socket hooks, security_unix_stream_connect(),
security_unix_may_send(), and security_socket_connect() don't provide
TOCTOU-free / namespace independent access to the paths of sockets.

(1) We cannot resolve the path from the struct sockaddr in existing hooks.
This requires another path lookup. A change in the path between the
two lookups will cause a TOCTOU bug.

(2) We cannot use the struct path from the listening socket, because it
may be bound to a path in a different namespace than the caller,
resulting in a path that cannot be referenced at policy creation time.

Consumers of the hook wishing to reference @other are responsible
for acquiring the unix_state_lock and checking for the SOCK_DEAD flag
therein, ensuring the socket hasn't died since lookup.

Cc: Günther Noack 
Cc: Tingmao Wang 
Cc: Mickaël Salaün 
Cc: Paul Moore 
Signed-off-by: Justin Suess 
Signed-off-by: Günther Noack 
Reviewed-by: Georgia Garcia 
Acked-by: Paul Moore 
Link: https://lore.kernel.org/r/20260327164838.38231-2-gnoack3000@gmail.com
Signed-off-by: Mickaël Salaün

lsm: add backing_file LSM hooks

2026-04-03T20:53:50+00:00

Stacked filesystems such as overlayfs do not currently provide the
necessary mechanisms for LSMs to properly enforce access controls on the
mmap() and mprotect() operations.  In order to resolve this gap, a LSM
security blob is being added to the backing_file struct and the following
new LSM hooks are being created:

 security_backing_file_alloc()
 security_backing_file_free()
 security_mmap_backing_file()

The first two hooks are to manage the lifecycle of the LSM security blob
in the backing_file struct, while the third provides a new mmap() access
control point for the underlying backing file.  It is also expected that
LSMs will likely want to update their security_file_mprotect() callback
to address issues with their mprotect() controls, but that does not
require a change to the security_file_mprotect() LSM hook.

There are a three other small changes to support these new LSM hooks:
* Pass the user file associated with a backing file down to
alloc_empty_backing_file() so it can be included in the
security_backing_file_alloc() hook.
* Add getter and setter functions for the backing_file struct LSM blob
as the backing_file struct remains private to fs/file_table.c.
* Constify the file struct field in the LSM common_audit_data struct to
better support LSMs that need to pass a const file struct pointer into
the common LSM audit code.

Thanks to Arnd Bergmann for identifying the missing EXPORT_SYMBOL_GPL()
and supplying a fixup.

Cc: stable@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-unionfs@vger.kernel.org
Cc: linux-erofs@lists.ozlabs.org
Reviewed-by: Amir Goldstein 
Reviewed-by: Serge Hallyn 
Reviewed-by: Christian Brauner 
Signed-off-by: Paul Moore

xen/privcmd: add boot control for restricted usage in domU

2026-03-20T11:06:01+00:00

When running in an unprivileged domU under Xen, the privcmd driver
is restricted to allow only hypercalls against a target domain, for
which the current domU is acting as a device model.

Add a boot parameter "unrestricted" to allow all hypercalls (the
hypervisor will still refuse destructive hypercalls affecting other
guests).

Make this new parameter effective only in case the domU wasn't started
using secure boot, as otherwise hypercalls targeting the domU itself
might result in violating the secure boot functionality.

This is achieved by adding another lockdown reason, which can be
tested to not being set when applying the "unrestricted" option.

This is part of XSA-482

Signed-off-by: Juergen Gross 
---
V2:
- new patch

lsm: make keys for static branch static

2026-01-07T01:57:55+00:00

The key use for static-branches are not refrenced by name outside
of the security/security.c file, so make them static. This stops
the sparse warnings about "Should it be static?" such as:

security/security.c: note: in included file:
./include/linux/lsm_hook_defs.h:29:1: warning: symbol
  'security_hook_active_binder_set_context_mgr_0' was not declared.
  Should it be static?
./include/linux/lsm_hook_defs.h:29:1: warning: symbol
  'security_hook_active_binder_set_context_mgr_1' was not declared.
  Should it be static?
...

Signed-off-by: Ben Dooks 
[PM: trimmed sparse output for line-length, readability]
Signed-off-by: Paul Moore

lsm: cleanup the debug and console output in lsm_init.c

2025-10-22T23:24:23+00:00

Move away from an init specific init_debug() macro to a more general
lsm_pr()/lsm_pr_cont()/lsm_pr_dbg() set of macros that are available
both before and after init.  In the process we do a number of minor
changes to improve the LSM initialization output and cleanup the code
somewhat.

Reviewed-by: Casey Schaufler 
Reviewed-by: John Johansen 
Signed-off-by: Paul Moore

lsm: rework lsm_active_cnt and lsm_idlist[]

2025-10-22T23:24:19+00:00

Move the LSM active count and lsm_id list declarations out of a header
that is visible across the kernel and into a header that is limited to
the LSM framework.  This not only helps keep the include/linux headers
smaller and cleaner, it helps prevent misuse of these variables.

Reviewed-by: Casey Schaufler 
Reviewed-by: John Johansen 
Reviewed-by: Mimi Zohar 
Signed-off-by: Paul Moore

lsm: split the init code out into lsm_init.c

2025-10-22T23:24:16+00:00

Continue to pull code out of security/security.c to help improve
readability by pulling all of the LSM framework initialization
code out into a new file.

No code changes.

Reviewed-by: Kees Cook 
Reviewed-by: John Johansen 
Reviewed-by: Casey Schaufler 
Reviewed-by: Mimi Zohar 
Signed-off-by: Paul Moore

lsm: split the notifier code out into lsm_notifier.c

2025-10-22T23:24:15+00:00

In an effort to decompose security/security.c somewhat to make it less
twisted and unwieldy, pull out the LSM notifier code into a new file
as it is fairly well self-contained.

No code changes.

Reviewed-by: Kees Cook 
Reviewed-by: John Johansen 
Reviewed-by: Casey Schaufler 
Reviewed-by: Mimi Zohar 
Signed-off-by: Paul Moore