On Wed, Oct 18, 2023 at 10:13 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Mon, Jun 12, 2023 at 5:01 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > > 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 <omosnace@xxxxxxxxxx> > > --- > > security/selinux/hooks.c | 27 +++++++++++++++++++ > > .../selinux/include/initial_sid_to_string.h | 2 +- > > security/selinux/include/policycap.h | 1 + > > security/selinux/include/policycap_names.h | 3 ++- > > security/selinux/include/security.h | 7 +++++ > > security/selinux/ss/policydb.c | 27 +++++++++++++++++++ > > 6 files changed, 65 insertions(+), 2 deletions(-) > > Unfortunately we had to revert this due to compatibility issues, but I > was hoping there might be a new, fixed version by now; any updates > Ondrej? Not yet, sorry... Haven't had time to sit down to it yet, but it's one of my top priorities this quarter and I hope to have a patch posted around early November (at worst). -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
