Re: staff_r

[Russell Coker <russell@coker.com.au>]

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)

> 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.

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?

Is staff_r supposed to be used for graphical logins or just for text based 
admin tasks?

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()?

> 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.

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.  

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/