Re: staff_r

[Dominick Grift <dominick.grift@defensec.nl>]

Russell Coker <russell@coker.com.au> writes:

> On Wednesday, 13 May 2026 21:20:21 AEST Dominick Grift wrote:
>> Russell Coker <russell@coker.com.au> 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