5.3. Practice

Role Based Access Controls (RBAC) offer a system or security administrator a means to define a role of some sort. In our example below we’ll be using a web admin role.

Normal access controls are fraught with problems of trust. To make somebody a true webadmin in traditional Linux systems requires a lot of effort:

The user must be able to read/write web content.
The user must be able read/write configuration files.
The user must be able to restart web services.
The user must be able to alter php configuration files.
The user must be able to read/write home directory content (if say apache uses mod_userdir).
The user must be able to read/write the temporary files that the http service generates (php sessions and genuine temp files).
The user must be able to change permissions of web content.

To manage this level of access on a traditional system would be nigh on impossible. You might be able to get a lot of it done through the use of file ACLs and sudo but it would be a nightmare to manage and make sure not to permit too much or too little access.

Normally one needs to be able to define what the limits of the role are in order to implement it. But the SELinux policy in EL6 already comes with predefined roles, such as web admin which can be implemented without too much trouble.

5.3.1. Demonstration

We are going to demonstrate how to do the above in a secure way which gives a system administrator the confidence to delegate trust.

First login to remote system, use ssh Client. Login as bviXY and password is bezpecnost
Note
See Chapter 2, Cvičenie 1/Practice 1 - Connection Setup
Login bviXY is given by lector
Open VirtualBox and run CentOS virtual machine
Login as root/password
Install necessary packages
```
$ yum -y install policycoreutils-python
```
Firstly, we’ll add the user onto the system as a web administrator. Enter following commands:
```
$ useradd webadministrator
```
```
$ passwd webadministrator
```
Next, we’ll create an SELinux User and assign our UID to use it:
```
$ semanage user -a -R "staff_r system_r webadm_r" -L s0 -r s0 webadm_u
```
```
$ semanage login -a -s webadm_u webadministrator
```
Line 1 creates the webadm_u SELinux user (this is distinctly different from a UNIX user account) which is mapped to roles it can be part of.
What we have done is assigned it to the staff, system and webadm roles. ‘Staff’ is a restricted account which can su and sudo which is what we’re going to need to permit, the system role is used here because its needed to run init scripts (to start/stop httpd), and finally our webadm role is the actual primary role of this user. It’s not possible to map the webadm role directly and only to this user because webadm_r doesnt actually have enough privileges to get it to login via SSH. So instead we use the loginable staff role and transition to the webadm role when we want to do work. The -l and -r are sensitivities. This isnt used in SELinux but its mandatory to pass something to it.
Line 2 maps the actual UNIX user webadministrator to the SELinux user webadm_u, so when the user logs in this will be their identifiable user.
We have listed 3 roles the SELinux user webadm_u can transition into. But, how do we know which one to transition into by default? Well – the answer to this is the folder: /etc/selinux/targeted/contexts/users. This folder contains a list of SELinux users you already have. If you open the file staff_u file you’ll see something like this:
```
$ cat  /etc/selinux/targeted/contexts/users/staff_u
```
```
system_r:local_login_t:s0 staff_r:staff_t:s0
sysadm_r:sysadm_t:s0 system_r:remote_login_t:s0 staff_r:staff_t:s0
system_r:sshd_t:s0 staff_r:staff_t:s0 sysadm_r:sysadm_t:s0
system_r:crond_t:s0 staff_r:staff_t:s0 system_r:xdm_t:s0
staff_r:staff_t:s0 staff_r:staff_su_t:s0 staff_r:staff_t:s0
staff_r:staff_sudo_t:s0 staff_r:staff_t:s0 system_r:initrc_su_t:s0
staff_r:staff_t:s0 staff_r:staff_t:s0 staff_r:staff_t:s0
sysadm_r:sysadm_su_t:s0 sysadm_r:sysadm_t:s0
sysadm_r:sysadm_sudo_t:s0 sysadm_r:sysadm_t:s0
```
This file is a two columned list of which role/types to map to users depending on how they enter the system. So for example the type “local_login_t” represents accessing from a console directly whereas the type “sshd_t” represents logging in via SSH. To the right of these entries is a left-to-right priority list of what contexts the staff_u user ends up getting when they login. Its not important to know all about how this works. All we really need to do is copy this file and name it webadm_u in the same directory:
```
$ cp /etc/selinux/targeted/contexts/users/staff_u  /etc/selinux/targeted/contexts/users/webadm_u
```
OK so now we have initialized our webadm_u user for logging in.
The UNIX user webadministrator cant do some of the things it needs to to properly function – such as restart the httpd service or change file ownerships/permissions when necessary. To do this webadm must become root. Becoming root means nothing to SELinux. It will enforce its policy all the same, so even as root webadministrator is restricted purely to the role that is needed. Thus we can safely do this without compromizing our system. We use sudo to do this which takes special tags we use to transition to our webadm role automatically so the user doesnt need to worry about the selinux particulars:
```
$ echo 'webadministrator ALL=(ALL) TYPE=webadm_t ROLE=webadm_r ALL' >> /etc/sudoers
```
This means that when the webadministrator runs sudo it will automatically transition into the webadm_t type and webadm_r role.
Logout from virtual machine
```
$ logout
```
Login to virtual as webadministrator and enter:
```
$ id -Z

OUTPUT
webadm_u:staff_r:staff_t:s0
```
```
$ sudo -s
```
```
$ id -Z 

OUTPUT
webadm_u:webadm_r:webadm_t:s0
```
So, we login via SSH as per the norm. When we login we check our ID (getting SELinux context). You can see we have logged in with webadm_u as the user but staff_r as the role and staff_t as the type. We can’t do much to our web content in this role and we’re also not root. When we sudo what happens is sudo auto-transitions the user into the webadm_r role and webadm_t type – just what the doctor ordered.
This role runs a very restricted set of actions it can take. Lets see what we can do…

We should be able to change the apache configuration and restart the service:

$ echo "# Add a comment to this file" >> /etc/httpd/conf/httpd.conf

$ /etc/init.d/httpd restart 
Stopping httpd: [ OK ]
Starting httpd: [ OK ]

However we can’t restart other services:

$ /etc/init.d/sshd restart 
bash: /etc/init.d/sshd: Permission denied

We can read, create and modify files in the document root:

$ cd /var/www/html

$ touch new_file.txt

$ rm new_file.txt

However we can’t modified files outside this:

$ echo "Port 20000" >> /etc/ssh/sshd_config
bash: /etc/ssh/sshd_config: Permission denied

$ cat /etc/shadow 
cat: /etc/shadow: Permission denied

So, here we are. As you can see, in the webadm role we can restart httpd (which webadministrator needs to do), write to our configuration files and alter our webcontent. However we can’t change anything outside of our remit or attempt to perform anything nefarious – all despite the fact we are root!