Why won't it let me transition from a staff_r role to a sysadm_r role?

[Daniel Skip]

Every time I run the command "sudo id -Z" it still says I am in the staff_r role when I should be in the sysadm_r role because that's how I set it up in my /etc/sudoers file which looks like this:

daniel  ALL=(ALL)  ROLE=sysadm_r  TYPE=sysadm_t  ALL

Furthermore, can anyone tell me what the best way to utilize RBAC on the targeted policy would be? I was looking at using the secadm_r for only installing policy instead of letting any other role do that but it looks like that would only work if I transitioned my system to a MLS system. Any ideas or help would be greatly appreciated.

[justina colmena ~biz]

On Sunday, March 21, 2021 8:08:32 AM AKDT Daniel Skip wrote:
> Every time I run the command "sudo id -Z" it still says I am in the staff_r
> role when I should be in the sysadm_r role because that's how I set it up
> in my /etc/sudoers file which looks like this:
> daniel  ALL=(ALL)  ROLE=sysadm_r  TYPE=sysadm_t  ALL
>
> Furthermore, can anyone tell me what the best way to utilize RBAC on the
> targeted policy would be? I was looking at using the secadm_r for only
> installing policy instead of letting any other role do that but it looks
> like that would only work if I transitioned my system to a MLS system. Any
> ideas or help would be greatly appreciated.

I'm not sure I can be of much help here, but I've been lurking here a while.

Corporate and government-centric bureaucratic Mandatory Access Control 
policies such as SELinux remain highly controversial here in the "real world." 
Essentially, "staff_r" is seen as a front-counter customer service position, 
and you're putting in for a promotion to "sysadm_r" which is a management 
role. It's a bit like you have to polish up your whole résumé or curriculum 
vitae in order to do something like that, and there's a great deal of 
resistance from "the usual" office politics, and all the "buddies" at work who 
want to make sure the Mob can still hack your system no matter what.

I use Fedora with the default "targeted" SELinux policies on my desktop but I 
have CentOS on OpenVZ shared-kernel virtualization "in the cloud" where 
SELinux is not really welcome anywhere from a professional customer service 
and support perspective.

The "KVM" virtualization options that would potentially support SELinux or any 
arbitary operating system setups in the cloud tend not to be adequately 
secured at the hardware simulation level in order for it to make sense to 
enable SELinux.

[justina@localhost ~]$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

[justina@amarillo ~]$ sestatus
SELinux status:                 disabled

[Daniel Skip]

Even though your reply wasn't much help since it didn't have anything to do with my code thanks for the reply. I fixed the issue no problem.

[Zdenek Pytela]

On Sun, Mar 21, 2021 at 5:12 PM Daniel Skip  wrote:
> Every time I run the command "sudo id -Z" it still says I am in the
> staff_r role when I should be in the sysadm_r role because that's how I set
> it up in my /etc/sudoers file which looks like this:
>
> daniel  ALL=(ALL)  ROLE=sysadm_r  TYPE=sysadm_t  ALL

I've just verified exactly this setting works as expected:

$ sudo id -Z

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
   #2) Think before you type.
   #3) With great power comes great responsibility.

[sudo] password for daniel:
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

Is there any additional information in the secure log, audit, journal?
Other sudo settings work?
> Furthermore, can anyone tell me what the best way to utilize RBAC on the
> targeted policy would be? I was looking at using the secadm_r for only
> installing policy instead of letting any other role do that but it looks
> like that would only work if I transitioned my system to a MLS system. Any
> ideas or help would be greatly appreciated.

Not completely sure what you have in mind, but you need to use the
semanage-user command to add an additional admin role for a selinux user:

semanage user -m -R "sysadm_r secadm_r unconfined_r staff_r" staff_u

See also this article for more information:
https://lukas-vrabec.com/index.php/2019/06/16/distinguish-sysadm-and-secadm-...

_______________________________________________
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[Daniel Skip]

I just fixed the issue. I was using it on the default user that has a name of "__default__" as a semanage login user so that's why it wasn't working. I had to create a new user and then map the staff_u user to my newly added linux user and everything worked fine.

But I was looking at all the denials and adding rules into a new policy but still it wouldn't work for whatever reason so just me creating a new linux user solved the issue no problem. Thanks for your help.