1. 10 Jul, 2023 2 commits
    • Ondrej Mosnacek's avatar
      selinux: introduce an initial SID for early boot processes · 5b0eea83
      Ondrej Mosnacek authored
      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: default avatarOndrej Mosnacek <omosnace@redhat.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      5b0eea83
    • Paul Moore's avatar
      selinux: cleanup the policycap accessor functions · d91c1ab4
      Paul Moore authored
      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: default avatarPaul Moore <paul@paul-moore.com>
      d91c1ab4
  2. 09 Jul, 2023 10 commits
  3. 08 Jul, 2023 28 commits