staff_r

staff_r

[Russell Coker]

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

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

Re: staff_r

[Dominick Grift]

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.

Practically that makes staff_r useful for confined
administration. Whereas user_t is not useful for that because user_t
cannot gain 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.

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

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

Re: staff_r

[Russell Coker]

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/

Re: staff_r

[Dominick Grift]

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