danwalsh

Sorry about not writing for a while, got wrapped up in work.

Roles Based Access Control with SELinux.

One of the underused features of SELinux is Roles Based Access Control (RBAC). In targeted policy RBAC is not really used. Everything pretty much runs in the same role (system_r).

The idea of SELinux RBAC is to define a role say auditadm_r which defines all the applications/files that a user in the role can run/manage. A user would log in as one of the default user roles and then when they wanted to administrate the audit programs they would have to change their roles. There is a newrole command for doing this. So a user might login in with the staff_r. The user would have to execute newrole -r auditadm_r, the tool will verify the role change is being done by a human being by prompting for the users password. At this point he would be allowed to execute all programs that can be run by the auditadm_r and would loose the ability to execute programs allowed to be run by staff_r. newrole also changes the Type of the running process. By convention the type matches the role so he would now be running in a shell of auditadm_r:auditadm_t. newrole is also the tool used to change the "Sensitivity Level" or MLS Level of the shell. One confusing part of changing the role is that you are also confined by the type, so files that you create will be relative to your type and role. And you will not necessarily have access to files in your home directory if the new role/type is not allowed access.

Remember SELinux is a parallel universe to DAC Controls. So if you needed to run applications as root, you will still need to use su or sudo to get around DAC Permissions.

In strict Policy we have defined the following roles

user_r which is the least powerful user. They can do everything a user can but do not have access to the administrators role.

staff_r which is very similar to user_r, except that staff_r can become other roles.

sysadm_r which is basically the administrator of the system role.

system_r which is the role of applications started by the system as opposed to applications started by a particular user or sysadm.

In MLS Policy we subdivide the sysadm_r role by adding:

auditadm_r which is allowed to control the auditing subsystem. He is allowed to change the audit rules and monitor the audit logs. He is not allowed to execute most SELinux utilities.

secadm_r who is allowed to run all of the selinux utilities. Change booleans, setenforce mode, load_policy, etc. He is not allowed to install software or do other administrative stuff.

sysadm_r has these priviledges removed.

MLS use of RBAC goal is not necessarily to stop a malicious admin from getting around these controls, but more to make them understand the role and stop them from making mistakes. For example, since the secadm_r can turn off enforcing mode, he could turn it off and then be allowed to manage the machine.

One of the experiments I would like to look into, would be to define a type say of apacheadm_t, which then could be allowed to only manipulate the apache configuration files. It would be an interesting experiment to see if we could allow this admin to run all editors and coreutils as root but only able to edit /etc/httpd and /var/www/html.

One problem with doing this blog is that sometimes I run out of ideas of what to talk about. (Writers Block). So please email me <dwalsh@redhat.com> with ideas of what you would like me to talk about.