kernel/linux.git/security/selinux/include/security.h, branch v6.12.80

selinux: fix style issues in security/selinux/include/security.h

2023-12-22T23:09:30+00:00

As part of on ongoing effort to perform more automated testing and provide more tools for individual developers to validate their patches before submitting, we are trying to make our code "clang-format clean". My hope is that once we have fixed all of our style "quirks", developers will be able to run clang-format on their patches to help avoid silly formatting problems and ensure their changes fit in well with the rest of the SELinux kernel code. Signed-off-by: Paul Moore

selinux: introduce an initial SID for early boot processes

2023-11-21T23:39:59+00:00

Currently, SELinux doesn't allow distinguishing between kernel threads and userspace processes that are started before the policy is first loaded - both get the label corresponding to the kernel SID. The only way a process that persists from early boot can get a meaningful label is by doing a voluntary dyntransition or re-executing itself. Reusing the kernel label for userspace processes is problematic for several reasons: 1. The kernel is considered to be a privileged domain and generally needs to have a wide range of permissions allowed to work correctly, which prevents the policy writer from effectively hardening against early boot processes that might remain running unintentionally after the policy is loaded (they represent a potential extra attack surface that should be mitigated). 2. Despite the kernel being treated as a privileged domain, the policy writer may want to impose certain special limitations on kernel threads that may conflict with the requirements of intentional early boot processes. For example, it is a good hardening practice to limit what executables the kernel can execute as usermode helpers and to confine the resulting usermode helper processes. However, a (legitimate) process surviving from early boot may need to execute a different set of executables. 3. As currently implemented, overlayfs remembers the security context of the process that created an overlayfs mount and uses it to bound subsequent operations on files using this context. If an overlayfs mount is created before the SELinux policy is loaded, these "mounter" checks are made against the kernel context, which may clash with restrictions on the kernel domain (see 2.). To resolve this, introduce a new initial SID (reusing the slot of the former "init" initial SID) that will be assigned to any userspace process started before the policy is first loaded. This is easy to do, as we can simply label any process that goes through the bprm_creds_for_exec LSM hook with the new init-SID instead of propagating the kernel SID from the parent. To provide backwards compatibility for existing policies that are unaware of this new semantic of the "init" initial SID, introduce a new policy capability "userspace_initial_context" and set the "init" SID to the same context as the "kernel" SID unless this capability is set by the policy. Another small backwards compatibility measure is needed in security_sid_to_context_core() for before the initial SELinux policy load - see the code comment for explanation. Signed-off-by: Ondrej Mosnacek Reviewed-by: Stephen Smalley [PM: edited comments based on feedback/discussion] Signed-off-by: Paul Moore

selinux: revert SECINITSID_INIT support

2023-08-09T14:51:13+00:00

This commit reverts 5b0eea835d4e ("selinux: introduce an initial SID for early boot processes") as it was found to cause problems on distros with old SELinux userspace tools/libraries, specifically Ubuntu 16.04. Hopefully we will be able to re-add this functionality at a later date, but let's revert this for now to help ensure a stable and backwards compatible SELinux tree. Link: https://lore.kernel.org/selinux/87edkseqf8.fsf@mail.lhotse Acked-by: Ondrej Mosnacek Signed-off-by: Paul Moore

selinux: avoid implicit conversions in services code

2023-08-04T02:19:57+00:00

Use u32 as the output parameter type in security_get_classes() and security_get_permissions(), based on the type of the symtab nprim member. Declare the read-only class string parameter of security_get_permissions() const. Avoid several implicit conversions by using the identical type for the destination. Use the type identical to the source for local variables. Signed-off-by: Christian Göttsche [PM: cleanup extra whitespace in subject] Signed-off-by: Paul Moore

selinux: update my email address

2023-07-19T15:27:02+00:00

Update my email address; MAINTAINERS was updated some time ago. Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore

selinux: avoid implicit conversions regarding enforcing status

2023-07-18T22:29:50+00:00

Use the type bool as parameter type in selinux_status_update_setenforce(). The related function enforcing_enabled() returns the type bool, while the struct selinux_kernel_status member enforcing uses an u32. Signed-off-by: Christian Göttsche [PM: subject line tweaks] Signed-off-by: Paul Moore

selinux: consistently use u32 as sequence number type in the status code

2023-07-18T22:29:47+00:00

Align the type with the one used in selinux_notify_policy_change() and the sequence member of struct selinux_kernel_status. Signed-off-by: Christian Göttsche [PM: subject line tweaks] Signed-off-by: Paul Moore

selinux: introduce an initial SID for early boot processes

2023-07-10T18:23:56+00:00

Currently, SELinux doesn't allow distinguishing between kernel threads and userspace processes that are started before the policy is first loaded - both get the label corresponding to the kernel SID. The only way a process that persists from early boot can get a meaningful label is by doing a voluntary dyntransition or re-executing itself. Reusing the kernel label for userspace processes is problematic for several reasons: 1. The kernel is considered to be a privileged domain and generally needs to have a wide range of permissions allowed to work correctly, which prevents the policy writer from effectively hardening against early boot processes that might remain running unintentionally after the policy is loaded (they represent a potential extra attack surface that should be mitigated). 2. Despite the kernel being treated as a privileged domain, the policy writer may want to impose certain special limitations on kernel threads that may conflict with the requirements of intentional early boot processes. For example, it is a good hardening practice to limit what executables the kernel can execute as usermode helpers and to confine the resulting usermode helper processes. However, a (legitimate) process surviving from early boot may need to execute a different set of executables. 3. As currently implemented, overlayfs remembers the security context of the process that created an overlayfs mount and uses it to bound subsequent operations on files using this context. If an overlayfs mount is created before the SELinux policy is loaded, these "mounter" checks are made against the kernel context, which may clash with restrictions on the kernel domain (see 2.). To resolve this, introduce a new initial SID (reusing the slot of the former "init" initial SID) that will be assigned to any userspace process started before the policy is first loaded. This is easy to do, as we can simply label any process that goes through the bprm_creds_for_exec LSM hook with the new init-SID instead of propagating the kernel SID from the parent. To provide backwards compatibility for existing policies that are unaware of this new semantic of the "init" initial SID, introduce a new policy capability "userspace_initial_context" and set the "init" SID to the same context as the "kernel" SID unless this capability is set by the policy. Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore

selinux: cleanup the policycap accessor functions

2023-07-10T18:23:56+00:00

In the process of reverting back to directly accessing the global selinux_state pointer we left behind some artifacts in the selinux_policycap_XXX() helper functions. This patch cleans up some of that left-behind cruft. Signed-off-by: Paul Moore

selinux: make labeled NFS work when mounted before policy load

2023-05-30T21:44:34+00:00

Currently, when an NFS filesystem that supports passing LSM/SELinux labels is mounted during early boot (before the SELinux policy is loaded), it ends up mounted without the labeling support (i.e. with Fedora policy all files get the generic NFS label system_u:object_r:nfs_t:s0). This is because the information that the NFS mount supports passing labels (communicated to the LSM layer via the kern_flags argument of security_set_mnt_opts()) gets lost and when the policy is loaded the mount is initialized as if the passing is not supported. Fix this by noting the "native labeling" in newsbsec->flags (using a new SE_SBNATIVE flag) on the pre-policy-loaded call of selinux_set_mnt_opts() and then making sure it is respected on the second call from delayed_superblock_init(). Additionally, make inode_doinit_with_dentry() initialize the inode's label from its extended attributes whenever it doesn't find it already intitialized by the filesystem. This is needed to properly initialize pre-existing inodes when delayed_superblock_init() is called. It should not trigger in any other cases (and if it does, it's still better to initialize the correct label instead of leaving the inode unlabeled). Fixes: eb9ae686507b ("SELinux: Add new labeling type native labels") Tested-by: Scott Mayhew Signed-off-by: Ondrej Mosnacek [PM: fixed 'Fixes' tag format] Signed-off-by: Paul Moore