From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from markus.defensec.nl (markus.defensec.nl [45.80.168.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE04448095B for ; Wed, 13 May 2026 15:15:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.80.168.93 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778685304; cv=none; b=Szsyt7/JuEbQcZuT4lfpX2dTYgRAYtOeUjNnHXQWUpkblQbySFu3bfg9dFn65CaKfnhrSf7WgdCat7LwSYPj19/NE++rX/C4nj25X5vObbpHEMy0nZcz7lzezjAFDvkPMkgzfswFoEuLAXu9a7BP7EORpqRnveTm1LJ/HpR9McE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778685304; c=relaxed/simple; bh=1AxbeXs5STSzNMcUg13tjMxoScQBMuH3qVKl3LBWPEU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=AMxoxieWobIpBh8xoQHX0OfXGvAg+8/LaFY9J/tVFQampHdDpqZ1Kh/vPZuj7HZtd1tFct9zs2+qL3Jz07yaBHqqT/TstPAX+Z9evIOBQ+/qFRYvnnzcgZRJPRy5o/JxqhE2Tk2RettKmKBvn0+bt+j/esSyNfyEd+lc73822SE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=defensec.nl; spf=pass smtp.mailfrom=defensec.nl; dkim=pass (1024-bit key) header.d=defensec.nl header.i=@defensec.nl header.b=ILfUhLN+; arc=none smtp.client-ip=45.80.168.93 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=defensec.nl Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=defensec.nl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=defensec.nl header.i=@defensec.nl header.b="ILfUhLN+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=defensec.nl; s=default; t=1778685300; bh=1AxbeXs5STSzNMcUg13tjMxoScQBMuH3qVKl3LBWPEU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ILfUhLN+oR+XxqEHzaQ85sh7BvfTPmv8EZNqyALS1jVImx9o8IRZrLOFgZVadrKYA HZ+9hgPqBbGJdBuIhJjRF/gtpM2BzYAVPq6t5aUSZcUe747z30FRgEvCciF2g0tMV8 FdzXSoV4mY8ZxXPGFv55dLRyqwi/yGn67G1BIl4M= Received: from nimbus (nimbus.defensec.nl [IPv6:2a10:3781:2099::514]) by markus.defensec.nl (Postfix) with ESMTPSA id 9896C29E297; Wed, 13 May 2026 17:15:00 +0200 (CEST) From: Dominick Grift To: Russell Coker Cc: selinux-refpolicy@vger.kernel.org Subject: Re: staff_r In-Reply-To: <23103313.EfDdHjke4D@dojacat> (Russell Coker's message of "Thu, 14 May 2026 00:21:58 +1000") References: <3505047.e9J7NaK4W3@dojacat> <87zf23imiy.fsf@defensec.nl> <23103313.EfDdHjke4D@dojacat> Date: Wed, 13 May 2026 17:15:00 +0200 Message-ID: <87v7cribnv.fsf@defensec.nl> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: selinux-refpolicy@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Russell Coker writes: > On Wednesday, 13 May 2026 21:20:21 AEST Dominick Grift wrote: >> Russell Coker writes: >> > Is there any point to staff_r? >> > >> > Currently it is a long way from usable for GUI sessions. >> > >> > For terminal sessions the isolation between staff_r and user_r is matched >> > by the isolation between user identities. >> >> The idea, I believe, is that the difference between user_t and staff_t >> is that the latter has access to privileges via su, sudo and >> etc. staff_t is user user_t with access to root. > > My idea when I created staff_r was to have a role that's protected from user_r > but not with the full access of sysadm_r. If MCS was a thing then I would > have just used different categories. Logging in via ssh to staff_r and then > "newrole -r sysadm_r" was a thing. At least one "Play Machine" was broken due > to allowing "newrole -r sysadm_r" from user_r, but I'm not aware of any > scenarios in which a staff_r is needed in real life since MCS became a thing. > > The uses of things can evolve so it would be possible to have certain roles > only used for su/sudo, but in the current policy they are all allowed it. > > auditadm.te: sudo_role_template(auditadm, auditadm_t, > auditadm_application_exec_domain, auditadm_r) > secadm.te: sudo_role_template(secadm, secadm_t, > secadm_application_exec_domain, secadm_r) > staff.te: sudo_role_template(staff, staff_t, > staff_application_exec_domain, staff_r) > sysadm.te: sudo_role_template(sysadm, sysadm_t, > sysadm_application_exec_domain, sysadm_r) > unprivuser.te: sudo_role_template(user, user_t, > user_application_exec_domain, user_r) > > auditadm.te: su_role_template(auditadm, auditadm_t, > auditadm_application_exec_domain, auditadm_r) > secadm.te: su_role_template(secadm, secadm_t, > secadm_application_exec_domain, secadm_r) > staff.te: su_role_template(staff, staff_t, > staff_application_exec_domain, staff_r) > sysadm.te: su_role_template(sysadm, sysadm_t, > sysadm_application_exec_domain, sysadm_r) > unprivuser.te: su_role_template(user, user_t, > user_application_exec_domain, user_r) Interesting. Maybe I am wrong but in my opinion those su_role_template() and sudo_role_template() calls do not belong in the unprivuser.te module. > >> Practically that makes staff_r useful for confined >> administration. Whereas user_t is not useful for that because user_t >> cannot gain root. > > auditadm.te: sysadm_role_change(auditadm_r, auditadm_t) > secadm.te: sysadm_role_change(secadm_r, secadm_t) > staff.te: sysadm_role_change(staff_r, staff_t) > > It can gain root but only auditadm_r, secadm_r, and staff_r can get sysadm_r. Yes that seems inconsistent. See above. > > The staff_t domain has a handful of extra sysadmin type permissions such as > corenet_ib_access_unlabeled_pkeys(), why does it have that? > > Also that corenet_ib_access_unlabeled_pkeys() interface is just a wrapper for > kernel_ib_access_unlabeled_pkeys() - why? unclear: https://github.com/SELinuxProject/refpolicy/commit/25a5b2427447eb14edb07ce302217d37528813bc > > Is staff_r supposed to be used for graphical logins or just for text based > admin tasks? I don't see why it couldnt be used for graphical logins. This functionality is not used much and so it does not receive much attention (especially in a gui scenario) > > What about sysadm_r is that supposed to be used for graphical tasks like > evolution_role() and gnome_role_template() as well as things like games_role() > and irc_role()? In my view sysadm_r should not be allowed to log in with a desktop manager because root gui logins are discouraged to say the least and sysadm_r is a privileged role (privileged roles are meant to be used with root) > >> These days things are more complicated with other ways to gain >> privileges like policykit and others but the essence is, AFAIK, still >> the same and even though systemd and others can leverage policykit even >> in a non-gui environment it is still optional functionality. > > One of the advantages of SE Linux is the ability to analise rules. But as > such analysis is based on domain/type not on identity and role we can't see > the distinction between different roles (which don't make it to labels for > objects). So when you have staff_r and user_r using the same types for home > directories etc you have to just know that only the identity keeps them apart. > >> > The role transition rules generally aren't used for anything and the roles >> > permitted to an identity determine what role transitions can be used. >> > >> > The vast majority of use of the reference policy is for "targeted" >> > configurations without even using user_r. >> > >> > Is there any reason for keeping staff_r? >> >> Reference policy is a hybrid between strict and targeted. You can remove >> or disable the targeted aspect and effectively enforce a strict policy >> and this is where these confined login user domains are essential. > > You have to remove the unconfined module to have fully confined users. The > mono_t and wine_t domains can be entered from user_t and are unconfined. So > the limitations on user_t when you have the unconfined module loaded and wine > or mono installed are those which the wine and mono runtimes decide to put in > place. I guess its a compromise and in practice few will probably login with a gui as user_t unless they have the unconfined module disabled and that then in turn will make wine and mono confined. > > The problem we have is that we have a lot of roles with no plans that haven't > been lost to time and no documentation that I'm aware of. So we have *_admin > interfaces called from sysadm.te for all the daemons that were around when we > transitioned to modular policy (which makes sysadm.te larger than all the > other role files combined) but no such interfaces for newer domains. I don't necessarily believe that it is a "problem" that allow rules are missing unless/until someone actually has a valid/good use-case for them and is also contributing/maintaining those rules upstream. Just my personal view on these matters though. I haven't used reference policy and derivatives for more than a decade. -- gpg --auto-key-locate clear,nodefault,wkd --locate-external-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift Mastodon: @kcinimod@defensec.nl