Pull lsm updates from Paul Moore: - Add LSM hooks, object blobs, and audit records for namespaces Add the necessary bits to enable LSMs to enforce access controls on the management of various kernel namespaces. While this pull request does not contain any in-tree users of these hooks, the Landlock pull request for Linux v7.4 will include Landlock support and the next merge window will likely include SELinux support as well. Considering the development behind these hooks, I expect that BPF LSM developers will also be making use of the namespace hooks, if they haven't already. - Update the inode LSM hooks to include mount idmaps This allows LSMs to incorporate the mount ID mapping into their access control decisions. While there are no current in-tree users of this, it was requested by those developing BPF LSM programs and this pull request includes a BPF LSM selftest. - Preserve the full 32-bit ioctl command in LSM audit records Previously only the low 16 bits were logged, ignoring the direction and size information in the upper 16 bits. The pull request also includes a Landlock based selftest to verify the full 32-bit ioctl value. - Ensure we don't call security_backing_file_free() multiple times Thankfully we don't have a problem with the current code base, but we want to fix this behavior now before it becomes a problem. - Clarify that only the current task may access current->cred The current code is a bit misleading around safely accessing the cred field in a task struct. Through comment and code corrections, this pull request clarifies that only the task itself may access its cred field. - Add SLAB_NO_MERGE to the credential object cache Harden the credential cache by ensuring credential objects live on dedicated slab pages. - Make use of safe memory zero'ing in the LSM Rust bindings - Update the docs for the current behavior of /sys/kernel/security/lsm - Update the docs for CONFIG_LSM and the "lsm=" command line option - Remove unnecessary code * tag 'lsm-pr-20261016' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: lsm: remove redundant NULL check in security_init() selftests/landlock: Check full ioctl commands in audit records lsm: Preserve full ioctl commands in audit records doc: fix LSM ordering description for /sys/kernel/security/lsm doc: describe CONFIG_LSM and lsm= as the selection mechanism selftests/bpf: verify mount idmaps reach inode hooks lsm: expose mount idmaps to inode hooks rust: lsm: replace `core::mem::zeroed` with `pin_init::zeroed` cred: prevent slab cache merging for cred_jar lsm: don't call security_backing_file_free() multiple times lsm: delete duplicate assignment in lsm_prepare() lsm: update the BUILD_BUG_ON() in audit_log_lsm_data() lsm: add LSM_AUDIT_DATA_NS for namespace audit records lsm: add LSM blob and hooks for namespaces ns: Free anonymous mount namespaces via ns_common_free() cred: clarify that task_struct::cred is only for the current task
Convert to const struct mnt_idmap. A mount's idmapping is immutable. The only thing that is allowed to be modified afterwards is the reference count and that is hidden behind mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads from the idmapping. This is the same model that struct cred uses and the idmapping is also rather sensitive. So make the idmap argument const wherever we can. The conversion is done from the bottom up so callers can continue to pass a non-const pointer to a const parameter until the conversion is finished. No functional changes. Link: https://patch.msgid.link/20260901-work-idmap-const-v1-24-54ccd48e100b@kernel.org Acked-by: Paul Moore <paul@paul-moore.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Seth Forshee <sforshee@kernel.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert to const struct mnt_idmap. A mount's idmapping is immutable. The only thing that is allowed to be modified afterwards is the reference count and that is hidden behind mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads from the idmapping. This is the same model that struct cred uses and the idmapping is also rather sensitive. So make the idmap argument const wherever we can. The conversion is done from the bottom up so callers can continue to pass a non-const pointer to a const parameter until the conversion is finished. No functional changes. Link: https://patch.msgid.link/20260901-work-idmap-const-v1-13-54ccd48e100b@kernel.org Acked-by: Paul Moore <paul@paul-moore.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Seth Forshee <sforshee@kernel.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Convert to const struct mnt_idmap. A mount's idmapping is immutable. The only thing that is allowed to be modified afterwards is the reference count and that is hidden behind mnt_idmap_get() and mnt_idmap_put(). Everything else only ever reads from the idmapping. This is the same model that struct cred uses and the idmapping is also rather sensitive. So make the idmap argument const wherever we can. The conversion is done from the bottom up so callers can continue to pass a non-const pointer to a const parameter until the conversion is finished. No functional changes. Link: https://patch.msgid.link/20260901-work-idmap-const-v1-11-54ccd48e100b@kernel.org Acked-by: Paul Moore <paul@paul-moore.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Seth Forshee <sforshee@kernel.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
OverlayFS performs upper-layer operations through inode-based security hooks. Those hooks receive the upper inode and dentry, but not the mount idmap used by the VFS operation. The security layer cannot distinguish an identity-mapped upper from an idmapped one or make the same ownership decision as the VFS. The VFS layer already passes the idmap down into all relevant inode operations so this just brings the security hooks to parity. So pass the mount idmap through the create, link, symlink, mkdir, mknod, and permission hooks. Update the in-tree security implementations and non-VFS callers accordingly. Signed-off-by: Daan De Meyer <daan@amutable.com> Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org> [PM: updated the commit description as discussed on-list] Signed-off-by: Paul Moore <paul@paul-moore.com>
Pull smack updates from Casey Schaufler:
- Spelling fix
- Code optimization in smackfs
- Fix credential mis-uses
- Place limits on two of the smackfs interfaces
* tag 'Smack-for-7.3' of https://github.com/cschaufler/smack-next:
smack: fix cred UAF in smack_file_send_sigiotask()
smack: restrict smackfs/{direct,mapped} values to 0-255
smack: deduplicate smackfs/{direct,mapped} file_operations
smack: show msgrcv() subject task in audit
smack: fix incorrect task context in smack_msg_queue_msgrcv
security: smack: fix spelling mistake
smack: simplify write handlers of sysfs entries
Smack: Fix error in capability bypass
When inspecting the credentials of another task, objective credentials (->real_cred, accessed with __task_cred()) must always be used. Accessing ->cred on a non-current task is forbidden unless that task is being created or destroyed; a task is allowed to change its own ->cred pointer with no synchronization, and changing ->cred should only affect the current syscall. smack_file_send_sigiotask() was accessing both sets of credentials: First tsk->cred, then __task_cred(tsk). Fix it, always access the objective credentials here. I have tested that this bug can lead to a KASAN-reported UAF of struct cred in smack_file_send_sigiotask(), and that this fix prevents the race. Cc: stable@vger.kernel.org Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Both smackfs/direct and smackfs/mapped incorrectly accept
the full range of integer values. For example:
# cd /sys/fs/smackfs/
# cat direct ; echo
250
# cat cipso2
@ 250/2
_ 250/2,4,5,6,7,8
* 250/3,5,7
^ 250/2,4,5,6,7
? 250/3,4,5,6,7,8
# echo -1234 >direct ; cat direct ; echo
-1234
# cat cipso2
@ -1234/2
_ -1234/2,4,5,6,7,8
* -1234/3,5,7
^ -1234/2,4,5,6,7
? -1234/3,4,5,6,7,8
#
I noticed two things regarding this:
1) sensitivity levels are truncated to 8 bits when labeling
outgoing packets (0x2e = 46 for the -1234 example above)
2) the reverse process fails: incoming packets with sensitivity
level 46 do not match these smackfs/cipso2 entries.
Even observation (1) on its own warrants a fix.
This patch restricts smackfs/direct and smackfs/mapped
accepted values to the 0-255 range.
Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel")
Signed-off-by: Konstantin Andreev <andreev@swemel.ru>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
The file_operations for smackfs/direct and smackfs/mapped are
identical up to a textual replacement of "direct" with "mapped"
This patch combines two instances of file_operations into one,
handling both files.
Fixes: f7112e6c9abf ("Smack: allow for significantly longer Smack labels v4")
Signed-off-by: Konstantin Andreev <andreev@swemel.ru>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
When a task msgrcv()'es some message the SMACK audit log message looks like: fn=smk_tskacc_msq action=denied subject="bar" object="foo" requested=rw pid=456 comm="mrcv" ipc_key=2 fn=smk_tskacc_msq action=granted subject="bar" object="foo" requested=rw pid=519 comm="mrcv" ipc_key=2 where pid= is a pid of a “current” task which calls smk_tskacc_msq(). Usually, the caller of smk_tskacc_msq() is also a subject task which determines its own permission. In the example above the 'mrcv' process has label 'bar' and wants "rw" for label "foo". However, when sender task delivers message using ipc/msg.c`pipelined_send(): ` security_msg_queue_msgrcv(,, msr->r_tsk,,) ` smp_store_release(&msr->r_msg, msg) “current” task and “subject” task differ, and the “subject” task is missed from the audit message. This patch adds two fields, subj_pid and subj_comm, into the audit message: fn=smk_tskacc_msq action=granted subject="bar" object="foo" requested=rw subj_pid=564 subj_comm="mrcv" pid=577 comm="msnd" ipc_key=2 Signed-off-by: Konstantin Andreev <andreev@swemel.ru> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>