Mystaff SELinux User Domain

The staff module provided by Refpolicy is pretty cool but i needed a user domain with less privileges that would be able to transition to privileged admin domains.

One of my requirements was that this User Domain should only be accessible via OpenSSH and that it should be identical to the guest_t User Domain or have even less privileges. The guest_t User Domain was designed to not User Domain transition ever.

Another requirement for my mystaff User Domain was that this user should not be able to change passwords. I did this because the provided staff_t User Domain by Tresys can change passwords. If i sudo to root in the staff_t User Domain than in theory i would be able to change the root password. This is something i wanted to prevent for mystaff user.

Generally i wanted mystaff to have as little privileges as possible. It would be a very restricted login environment only accessible with OpenSSH that would be able to transition to specified admin User domains like for example webadm_t.

I started by reverse engineering the staff_t User Domain:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/roles/staff.te
http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/roles/staff.if

The staff.te file is mostly one call to a interface that is defined in the userdom modules interface file:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/system/userdomain.if ( line 927 to line 1020)

So far so good, but this interface has calls to to included several other interfaces that are defined in the same interface files:

userdom_restricted_user_template($1)
userdom_common_user_template($1)

These interfaces have calls to yet other interfaces defined in userdom.if file and so forth and so forth.

userdom_login_user_template($1)
userdom_basic_networking_template($1)

Which call:

userdom_base_user_template($1)
userdom_manage_home_role($1_r, $1_t)
userdom_manage_tmp_role($1_r, $1_t)
userdom_manage_tmpfs_role($1_r, $1_t)
userdom_exec_user_tmp_files($1_t)
userdom_exec_user_home_content_files($1_t)
userdom_change_password_template($1)

My goal was to expand all these userdomain interfaces so that i could remove parts of policy in there that i did not need.

Since i did not want mystaff to be able to change passwords i could for example remove the userdom_change_password_template altogether.

I also wanted mystaff to easily be customizable for different admin domain transitions and i started making different admin domains based of off webadm User domain. Basically i edited the name and declarations and replace the apache_admin interface calls by admin interface calls for other services. I also remove some policy specific to webadm.

For example:

http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/aide.if (line 46 to line 71)

The interface to call for administration of the aide domain.

Long story short. Below you will find the links to the mystaff user domain that is based of off the staff domain provided by upstream. In mystaff module i have expanded all userdom interface calls and i have removed policy that i did not require.

Basically the mystaff_u SELinux user is even more restricted then guest_u but unlike guest_u, mystaff_u can use sudo to user domain transition to admin domains. By default i have it call the webadm_role_change interface which allows mystaff_r access to the already by default installed webadm_r role. I also used the gen_user() macro to generate a mystaff_u SELinux User. However this SELinux user does not yet have the webadm_r role mapped. One could simply use semanage user -m <...> mystaff_u to add the webadm_r or edit the gen_user() macro to recflect mystaff_u SELinux Users access to the webadm_r role.

You will also notice plenty commented role_change template calls for other services. One can simple uncomment any of these calls to allow mystaff_r access to the role these provides. This requires that you install the corresponding admin User domains which can be found in the same modules directory.
It is then also required to map any of these roles to the mystaff_u SELinux User.

http:///82.197.205.60/~dgrift/stuff/modules/mystaff.te
http:///82.197.205.60/~dgrift/stuff/modules/mystaff.if
http:///82.197.205.60/~dgrift/stuff/modules/mystaff.fc

Other source policy modules:
http:///82.197.205.60/~dgrift/stuff/modules/

By the way: the mystaff module can be easily modified to reflect a myguest modified guest User Domain. Just comment:

optional_policy(`
sudo_role_template(mystaff, mystaff_r, mystaff_t)
')

# Available privileged roles
# Test
optional_policy(`
webadm_role_change(mystaff_r)
')

In that case one may also want to rename the mystaff to something more appropriate. One can simply modify this policy to add or remove privileges.

Oh, by the way, do not forget to add default contexts for mystaff_u. You can base you mystaff_u default context file of off the staff_u file in /etc/selinux/targeted/contexts/users/. All you have to do is replace staff by mystaff in this file. (see my previous article on creating custom user domains)