Hello List,
Question about managing roles: I'm trying to setup my user to have access to both the unprivileged user_r role and the administrative role sysadm_r. My system is FC6 using the latest policy from yum:
<sestatus> SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: strict </sestatus>
I've created new SELinux user: semanage user -a -R sysadm_r -R user_r -P user MyUser_u
I've associated a Linux user with my SELinux user: semanage login -a -s MyUser_u MyUser
When I login with my new user I see ...
<shell> [MyUser@test ~]$ id -Z MyUser_u:user_r:user_t [MyUser@test ~]$ newrole -r sysadm_r -t sysadm_t Authenticating MyUser. Password: failed to exec shell : Permission denied [MyUser@test ~]$ </shell>
The initial role is user_r which I like. But when MyUser attempts to change to the new role (sysadm_r through use of newrole)... they cannot.
<avc> type=AVC msg=audit(1178544785.335:2418): avc: denied { transition } for pid=13798 comm="newrole" name="bash" dev=hda3 ino=162298 scontex=MyUser_u:user_r:newrole_t:s0 tcontext=MyUser_u:sysadm_r:sysadm_t:s0 tclass=process </avc>
The contexts in the avc denied message seem right: MyUser is running the newrole command and has successfully transitioned into the newrole_t domain. The problem seems to be that newrole cannot kick off a shell in the target context (MyUser_u:sysadm_r:sysadm_t).
A similar problem seems to arise when associating Linux users with user_r, staff_r and sysadm_r. The user will login with the default staff_r, will be able to newrole up to the sysadm_r role, but cannot change their role to user_r through similar means (newrole -r user_r -t user_t).
I'd assume it's a fairly standard practice to make an SELinux user with the user_r and sysadm_r roles, much like using an unprivileged Linux user and only performing admin tasks using root. I'm guessing I missed a step somewhere along the line ... would someone mind pointing out where I went wrong or what I might try to resolve this?
Cheers, - Philip
On Mon, 2007-05-07 at 15:03 -0400, Philip Tricca wrote:
Hello List,
Question about managing roles: I'm trying to setup my user to have access to both the unprivileged user_r role and the administrative role sysadm_r. My system is FC6 using the latest policy from yum:
[...]
I've created new SELinux user: semanage user -a -R sysadm_r -R user_r -P user MyUser_u
I've associated a Linux user with my SELinux user: semanage login -a -s MyUser_u MyUser
When I login with my new user I see ...
<shell> [MyUser@test ~]$ id -Z MyUser_u:user_r:user_t [MyUser@test ~]$ newrole -r sysadm_r -t sysadm_t Authenticating MyUser. Password: failed to exec shell : Permission denied [MyUser@test ~]$ </shell>
The initial role is user_r which I like. But when MyUser attempts to change to the new role (sysadm_r through use of newrole)... they cannot.
<avc> type=AVC msg=audit(1178544785.335:2418): avc: denied { transition } for pid=13798 comm="newrole" name="bash" dev=hda3 ino=162298 scontex=MyUser_u:user_r:newrole_t:s0 tcontext=MyUser_u:sysadm_r:sysadm_t:s0 tclass=process </avc>
[...]
A similar problem seems to arise when associating Linux users with user_r, staff_r and sysadm_r. The user will login with the default staff_r, will be able to newrole up to the sysadm_r role, but cannot change their role to user_r through similar means (newrole -r user_r -t user_t).
Allowed role changes are defined in the policy, and the stock policy does not allow a change of staff_r <-> user_r or user_r -> sysadm_r.
I'd assume it's a fairly standard practice to make an SELinux user with the user_r and sysadm_r roles
No, user_r is for generic unprivileged users. If you want an unprivileged user that can change to the sysadm_r, you should be using staff_r instead of user_r. User_r and staff_r basically have the same rules except staff_r can change to sysadm_r, where user_r can't.
Christopher J. PeBenito wrote:
On Mon, 2007-05-07 at 15:03 -0400, Philip Tricca wrote:
Hello List,
Question about managing roles: I'm trying to setup my user to have access to both the unprivileged user_r role and the administrative role sysadm_r. My system is FC6 using the latest policy from yum:
[...]
I've created new SELinux user: semanage user -a -R sysadm_r -R user_r -P user MyUser_u
I've associated a Linux user with my SELinux user: semanage login -a -s MyUser_u MyUser
When I login with my new user I see ...
<shell> [MyUser@test ~]$ id -Z MyUser_u:user_r:user_t [MyUser@test ~]$ newrole -r sysadm_r -t sysadm_t Authenticating MyUser. Password: failed to exec shell : Permission denied [MyUser@test ~]$ </shell>
The initial role is user_r which I like. But when MyUser attempts to change to the new role (sysadm_r through use of newrole)... they cannot.
<avc> type=AVC msg=audit(1178544785.335:2418): avc: denied { transition } for pid=13798 comm="newrole" name="bash" dev=hda3 ino=162298 scontex=MyUser_u:user_r:newrole_t:s0 tcontext=MyUser_u:sysadm_r:sysadm_t:s0 tclass=process </avc>
[...]
A similar problem seems to arise when associating Linux users with user_r, staff_r and sysadm_r. The user will login with the default staff_r, will be able to newrole up to the sysadm_r role, but cannot change their role to user_r through similar means (newrole -r user_r -t user_t).
Allowed role changes are defined in the policy, and the stock policy does not allow a change of staff_r <-> user_r or user_r -> sysadm_r.
I'd assume it's a fairly standard practice to make an SELinux user with the user_r and sysadm_r roles
No, user_r is for generic unprivileged users. If you want an unprivileged user that can change to the sysadm_r, you should be using staff_r instead of user_r. User_r and staff_r basically have the same rules except staff_r can change to sysadm_r, where user_r can't.
Excellent! I haven't ventured deep into the policy src yet, but a quick grep on staff_r shows everything you describe quite clearly in the policy/modules/system/userdomain files
After putting my user in staff_r & sysadm_r and relabeling my home dir everything works as expected.
Thanks, - Philip
selinux@lists.fedoraproject.org