linux-stable.git/security/smack, branch v6.18.2

smack: fix bug: setting task label silently ignores input garbage

2025-12-18T13:02:25+00:00

[ Upstream commit 674e2b24791cbe8fd5dc8a0aed4cb4404fcd2028 ]

This command:
    # echo foo/bar >/proc/$$/attr/smack/current

gives the task a label 'foo' w/o indication
that label does not match input.
Setting the label with lsm_set_self_attr() syscall
behaves identically.

This occures because:

1) smk_parse_smack() is used to convert input to a label
2) smk_parse_smack() takes only that part from the
   beginning of the input that looks like a label.
3) `/' is prohibited in labels, so only "foo" is taken.

(2) is by design, because smk_parse_smack() is used
for parsing strings which are more than just a label.

Silent failure is not a good thing, and there are two
indicators that this was not done intentionally:

    (size >= SMK_LONGLABEL) ~> invalid

clause at the beginning of the do_setattr() and the
"Returns the length of the smack label" claim
in the do_setattr() description.

So I fixed this by adding one tiny check:
the taken label length == input length.

Since input length is now strictly controlled,
I changed the two ways of setting label

   smack_setselfattr(): lsm_set_self_attr() syscall
   smack_setprocattr(): > /proc/.../current

to accommodate the divergence in
what they understand by "input length":

  smack_setselfattr counts mandatory \0 into input length,
  smack_setprocattr does not.

  smack_setprocattr allows various trailers after label

Related changes:

* fixed description for smk_parse_smack

* allow unprivileged tasks validate label syntax.

* extract smk_parse_label_len() from smk_parse_smack()
  so parsing may be done w/o string allocation.

* extract smk_import_valid_label() from smk_import_entry()
  to avoid repeated parsing.

* smk_parse_smack(): scan null-terminated strings
  for no more than SMK_LONGLABEL(256) characters

* smack_setselfattr(): require struct lsm_ctx . flags == 0
  to reserve them for future.

Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel")
Signed-off-by: Konstantin Andreev 
Signed-off-by: Casey Schaufler 
Signed-off-by: Sasha Levin

smack: fix bug: unprivileged task can create labels

2025-12-18T13:02:25+00:00

[ Upstream commit c147e13ea7fe9f118f8c9ba5e96cbd644b00d6b3 ]

If an unprivileged task is allowed to relabel itself
(/smack/relabel-self is not empty),
it can freely create new labels by writing their
names into own /proc/PID/attr/smack/current

This occurs because do_setattr() imports
the provided label in advance,
before checking "relabel-self" list.

This change ensures that the "relabel-self" list
is checked before importing the label.

Fixes: 38416e53936e ("Smack: limited capability for changing process label")
Signed-off-by: Konstantin Andreev 
Signed-off-by: Casey Schaufler 
Signed-off-by: Sasha Levin

smack: fix bug: invalid label of unix socket file

2025-12-18T13:02:25+00:00

[ Upstream commit 78fc6a94be252b27bb73e4926eed70b5e302a8e0 ]

According to [1], the label of a UNIX domain socket (UDS)
file (i.e., the filesystem object representing the socket)
is not supposed to participate in Smack security.

To achieve this, [1] labels UDS files with "*"
in smack_d_instantiate().

Before [2], smack_d_instantiate() was responsible
for initializing Smack security for all inodes,
except ones under /proc

[2] imposed the sole responsibility for initializing
inode security for newly created filesystem objects
on smack_inode_init_security().

However, smack_inode_init_security() lacks some logic
present in smack_d_instantiate().
In particular, it does not label UDS files with "*".

This patch adds the missing labeling of UDS files
with "*" to smack_inode_init_security().

Labeling UDS files with "*" in smack_d_instantiate()
still works for stale UDS files that already exist on
disk. Stale UDS files are useless, but I keep labeling
them for consistency and maybe to make easier for user
to delete them.

Compared to [1], this version introduces the following
improvements:

  * UDS file label is held inside inode only
    and not saved to xattrs.

  * relabeling UDS files (setxattr, removexattr, etc.)
    is blocked.

[1] 2010-11-24 Casey Schaufler
commit b4e0d5f0791b ("Smack: UDS revision")

[2] 2023-11-16 roberto.sassu
Fixes: e63d86b8b764 ("smack: Initialize the in-memory inode in smack_inode_init_security()")
Link: https://lore.kernel.org/linux-security-module/20231116090125.187209-5-roberto.sassu@huaweicloud.com/

Signed-off-by: Konstantin Andreev 
Signed-off-by: Casey Schaufler 
Signed-off-by: Sasha Levin

smack: always "instantiate" inode in smack_inode_init_security()

2025-12-18T13:02:25+00:00

[ Upstream commit 69204f6cdb90f56b7ca27966d1080841108fc5de ]

If memory allocation for the SMACK64TRANSMUTE
xattr value fails in smack_inode_init_security(),
the SMK_INODE_INSTANT flag is not set in
(struct inode_smack *issp)->smk_flags,
leaving the inode as not "instantiated".

It does not matter if fs frees the inode
after failed smack_inode_init_security() call,
but there is no guarantee for this.

To be safe, mark the inode as "instantiated",
even if allocation of xattr values fails.

Signed-off-by: Konstantin Andreev 
Signed-off-by: Casey Schaufler 
Stable-dep-of: 78fc6a94be25 ("smack: fix bug: invalid label of unix socket file")
Signed-off-by: Sasha Levin

smack: deduplicate xattr setting in smack_inode_init_security()

2025-12-18T13:02:24+00:00

[ Upstream commit 8e5d9f916a9678e2dcbed2289b87efd453e4e052 ]

Signed-off-by: Konstantin Andreev 
Signed-off-by: Casey Schaufler 
Stable-dep-of: 78fc6a94be25 ("smack: fix bug: invalid label of unix socket file")
Signed-off-by: Sasha Levin

smack: deduplicate "does access rule request transmutation"

2025-12-18T13:02:24+00:00

[ Upstream commit 635a01da8385fc00a144ec24684100bd1aa9db11 ]

Signed-off-by: Konstantin Andreev 
Signed-off-by: Casey Schaufler 
Stable-dep-of: 78fc6a94be25 ("smack: fix bug: invalid label of unix socket file")
Signed-off-by: Sasha Levin

smack: fix bug: SMACK64TRANSMUTE set on non-directory

2025-12-18T13:02:24+00:00

[ Upstream commit 195da3ff244deff119c3f5244b464b2236ea1725 ]

When a new file system object is created
and the conditions for label transmutation are met,
the SMACK64TRANSMUTE extended attribute is set
on the object regardless of its type:
file, pipe, socket, symlink, or directory.

However,
SMACK64TRANSMUTE may only be set on directories.

This bug is a combined effect of the commits [1] and [2]
which both transfer functionality
from smack_d_instantiate() to smack_inode_init_security(),
but only in part.

Commit [1] set blank  SMACK64TRANSMUTE on improper object types.
Commit [2] set "TRUE" SMACK64TRANSMUTE on improper object types.

[1] 2023-06-10,
Fixes: baed456a6a2f ("smack: Set the SMACK64TRANSMUTE xattr in smack_inode_init_security()")
Link: https://lore.kernel.org/linux-security-module/20230610075738.3273764-3-roberto.sassu@huaweicloud.com/

[2] 2023-11-16,
Fixes: e63d86b8b764 ("smack: Initialize the in-memory inode in smack_inode_init_security()")
Link: https://lore.kernel.org/linux-security-module/20231116090125.187209-5-roberto.sassu@huaweicloud.com/

Signed-off-by: Konstantin Andreev 
Signed-off-by: Casey Schaufler 
Signed-off-by: Sasha Levin

Merge tag 'pull-qstr' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2025-10-03T18:14:02+00:00

Pull d_name audit update from Al Viro:
 "Simplifying ->d_name audits, easy part.

  Turn dentry->d_name into an anon union of const struct qsrt (d_name
  itself) and a writable alias (__d_name).

  With constification of some struct qstr * arguments of functions that
  get &dentry->d_name passed to them, that ends up with all
  modifications provably done only in fs/dcache.c (and a fairly small
  part of it).

  Any new places doing modifications will be easy to find - grep for
  __d_name will suffice"

* tag 'pull-qstr' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  make it easier to catch those who try to modify ->d_name
  generic_ci_validate_strict_name(): constify name argument
  afs_dir_search: constify qstr argument
  afs_edit_dir_{add,remove}(): constify qstr argument
  exfat_find(): constify qstr argument
  security_dentry_init_security(): constify qstr argument

security_dentry_init_security(): constify qstr argument

2025-09-16T01:08:33+00:00

Nothing outside of fs/dcache.c has any business modifying
dentry names; passing &dentry->d_name as an argument should
have that argument declared as a const pointer.

Acked-by: Casey Schaufler  # smack part
Acked-by: Paul Moore 
Reviewed-by: Christian Brauner 
Signed-off-by: Al Viro

audit: add record for multiple object contexts

2025-08-30T14:15:30+00:00

Create a new audit record AUDIT_MAC_OBJ_CONTEXTS.
An example of the MAC_OBJ_CONTEXTS record is:

    type=MAC_OBJ_CONTEXTS
      msg=audit(1601152467.009:1050):
      obj_selinux=unconfined_u:object_r:user_home_t:s0

When an audit event includes a AUDIT_MAC_OBJ_CONTEXTS record
the "obj=" field in other records in the event will be "obj=?".
An AUDIT_MAC_OBJ_CONTEXTS record is supplied when the system has
multiple security modules that may make access decisions based
on an object security context.

Signed-off-by: Casey Schaufler 
[PM: subj tweak, audit example readability indents]
Signed-off-by: Paul Moore