Enabling MLS policy module in SELinux

This "experiment" is carried on late of August, 2009.

Environment: Fedora Core 11 (guest) under VirtualBox-3.0.4 on Ubuntu-9.0.4 (host)
MLS Policy Module Version: 3.6.12

Credits: Most information about SELinux comes from Red Hat Enterprise Linux 5 Deployment Guide [ref-G] and MLS setup procedures come from Fedora Project Wiki. And, Getting Started with SE Linux HOWTO gives me better understanding. If you like reading SELinux from academic paper, consult A logical specification and analysis for SELinux MLS policy.


SELinux Overview in Brief
---

Security-Enhanced Linux (SELinux) is a security architecture integrated into the 2.6.x kernel using the Linux Security Modules (LSM). It is a project of the United States National Security Agency (NSA) and the SELinux community. SELinux integration into Red Hat Enterprise Linux was a joint effort between the NSA and Red Hat.

-- 44.2. Introduction to SELinux, [ref-G]

In standard Linux Distro, there is Discretionary Access Control (DAC). Any process running as a user has the permission to any object (file, socket, executable...) as the user. A typical ls -l shows the permission of objects.



For example, the object "Mario_Gant" is owned by user and grouped under the group "user". The permission of the object is rwx:r-x:r-x for owner:group:others respectively. The owner - "user" is granted to read-write-execute of the object. The group - "user" is granted to read-execute. And, any person other than the owner or outside the group of "user" have the read-execute permission on the object. This is typical DAC on any Linux Distro.

SELinux builds another access control layer on top of DAC - the Mandatory Access Control (MAC). SELinux privilege checking is first carried on DAC and then MAC. If DAC denied the access, MAC is not carried. SELinux Decision Process is visualized in [ref-G] as shown below.



Any subject passed DAC checking fires an action request on an object to the SELinux Security Server, a.k.a. the policy enforcement server. The server consult the SELinux Policy Database, either from the Access Vector Cache (AVC) or security context matrix on disk, for policy on that particular object requested. The server grants permission to the subject according to policy consulted. If permission is denied, a denial message is logged.

There are 2 modes of operation in SELinux - Enforcing mode and Permissive mode. The only difference between 2 modes is that Permissive mode does not deny any unprivileged MAC attempt but those unprivileged attempts will be logged. Permissive mode is useful for troubleshooting and development of security contexts.

Security Contexts, User, Role, Type/Domain

SELinux security context of any object is stored as file attribute. Context of object can be viewed by issuing ls -Z. A typical context is shown below.

[root@myServer ~]# ls -Z gravityControl.txt
-rw-r--r--  user     user     user_u:object_r:tmp_t:Moonbase_Plans gravityControl.txt

user_u:object_r:tmp_t:Moonbase_Plans refers to {SELinux User}:{SELinux Role}:{SELinux Domain/Type}:{SELinux MCS/MLS Label} respectively.

Here, SELinux User is different to user in conventional Linux. For instance, a linux user 'pi' is configured as SELinux user "user_u". If 'pi' issue su command to login as 'root', he/she's SELinux user identity is still 'user_u' and thus security policies applied on 'user_u' still remains. Mapping between SELinux User and typical linux uid is maintained by SELinux Login. SELinux Login can be viewed by issuing semanage login -l

[root@dhcp-133 ~]# semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               user_u                    s0
james                     user_u                    s0
daniel                    user_u                    s0
root                      root                      s0-s0:c0.c1023
olga                      user_u                    s0

The first column is typical linux uid while second column is the SELinux user identity. The last column is the MLS/MCS (Multi Level Security/Multi Category System) Range. MLS and MCS is two different security policies. MLS will be explained in later section in this article.

In above example, different linux uids are mapped to two SELinux User. To obtain the definition of those SELinux User, issue semanage user -l

[root@dhcp-133 ~]# semanage user -l

                Labeling   MLS/       MLS/
SELinux User    Prefix     MCS Level  MCS Range            SELinux Roles

root            user       s0         s0-s0:c0.c1023       system_r sysadm_r user_r
system_u        user       s0         s0-s0:c0.c1023       system_r
user_u          user       s0         s0-s0:c0.c1023       system_r sysadm_r user_r

In this snap, SELinux User 'root' is having 3 different SELinux Roles while it's the same as 'user_u'. However, 'user_u' is being mapped to all typical linux uid while 'root' is mapped to uid 'root' as system administrator. The user, 'system_u', is dedicated for system processes.

Let's move on to SELinux Roles. It is part of SELinux Role-based Access Control and predefined in SELinux policies. SELinux Role determines which process domains / object types can be accessed. All processes under SELinux run under a domain. A domain specifies what can be performed by processes while a type specifies who can access an object.

Roles are predefined. For instance, 'system_r' is the role specifically for all system processes except user processes. It allows domains/types like .. dhcpd_t, httpd_t, initrc_t, and ldconfig_t. These domains/types are for dhcp daemon, http daemon, initrc script, and ldconfig respectively.



SELinux actually is not that complicated ... Let's keep it short! When you login, you obtain a role. This role can perform certain tasks according to predefined rules. Those rules make use of domain and type. So, if your role does not match the specified domain / type, permission deny as result. A SELinux user can have more than a single role. Thus, user may switch between role for certain tasks.


MLS Policy
---

MLS policy in SELinux is implemented like an add-on to SELinux MAC. MLS is abbreviation of Multi-Level Security. So, what is multi-level? It is actually derived from Bell-La Padula model.

The term multi-level arises from the defense community's security classifications: Confidential, Secret, and Top Secret. -- 44.6.1 Why Multi-Level, [ref-G]

In short, using the military terms, a general that can view national secret stuffs can also view national confidential stuffs and of course unclassified stuffs. But, general does not have enough privileges to view stuffs that are classified as national top secret like ... UFO ^^? On the other hand, a general would report to the upstreams but not report anything to the soldiers. (Like you have to report to your boss all the time @@?) This is the general belief behind Bell-La Padula model - "no read up, no write down".

To put this concept into SELinux, look at the self-explanatory visualization from [ref-G].



MLS further extends BLP by allowing categorization, a.k.a. compartment. For example, if UFO is considered as top secret, it belongs to the UFO category. At the same time, another top secret category would be Nuclear. Someone that is allowed to access top secret information related to UFO does not necessarily need to access information about Nuclear. You may consider as sub-levels.

SELinux implementation provides 16 default levels - from s0 (lowest) to s15 (highest), and 1024 categories - from c0 to c1023. Level can be added on demand by editing the file '/etc/selinux/mls/setrans.conf'. At the same time, MLS policy has its own set of roles definition. According to Fedora wiki, roles include: user_r, staff_r, sysadm_r, secadm_r, and auditadm_r. Other than that, DAC, SELinux Role, Type, and Domain still applies with MLS policy.


The Experiment - setup
---

Steps listed below are used to carry my experiment in enabling MLS policy in SELinux under FC11.

Friendly Reminders

[1] MLS Policy in FC11 is still "experimental" (I like this pretty word so that noone think it's buggy). You're suggested to do the following steps without the GUI so that you can always take the root access. To do so, edit the /etc/inittab and replace "id:5:initdefault:" with "id:3:initdefault:". Starting from now, the next boot of Fedora will fall into run-level 3.

[2] Whenever you lose your root access by any accident, GRUB will help! When booting your machine, pressing Esc-key will stop GRUB automatic boot process (You have to press Esc-key before Fedora is being booted). Then, press 'e' to edit the boot parameter under the boot menu. Append 'single' to the back of the line with something like .. 'kernel /vmlinuz-2.6. ... rhgb quiet' so that the line becomes something like 'kernel /vmlinuz-2.6. ... rhgb quiet single'. After that, pressing 'b' will start booting Fedora into single-user mode. After booting into single-user mode, you'll get a terminal without login. Type 'init 3' and hit your enter-key so that Fedora will boot into run-level 3.

[3] And... prevent trying the MLS policy with your working machine... vbox or any spare machine are better starting points for experiments.

1. Installing FC11 with the wonderful LiveCD.

2. Update your fresh installation in order to fix anything the update can fix

To update in FC11, Do the following as root.

yum update
reboot

*Note: I do this in my tea time ... as the update took me around 30minutes to complete.

3. Install and configure the MLS policy

Again, do as root.

yum install selinux-policy-mls

Then, vi the file '/etc/selinux/config' to configure SELinux. Setting the two config-variable as follows.

SELINUX=permissive
SELINUXTYPE=mls

This configuration tells SELinux to operate in permissive mode (the one mentioned in previous section that it just warns) and use the MLS policy.

4. Ask SELinux to relabel with MLS policy

Issue "touch /.autorelabel" in your terminal so that your next boot will ask SELinux to relabel stuffs with the MLS policy. Then, reboot into single-user mode (see friendly reminder [2] in order to know howto do so) and the relabeling will start. Once relabeling is finished, issue "init 3" to boot into run-level 3.

5. Enabling MLS policy and Getting Back the GUI

To turn on MLS policy, edit the file '/etc/selinux/config' and set 'SELINUX=enforcing'
To turn off MLS policy, edit the file '/etc/selinux/config' and set 'SELINUX=permissive'
To turn on GUI, edit the file '/etc/inittab' and set 'id:5:initdefault:'
To turn off GUI, edit the file '/etc/inittab' and set 'id:3:initdefault:'


The Experiment - tryout
---

Tips

[1] su and sudo are no longer the great. If your active user is having the role "user_r", you cannot su/sudo. If your active user is having the role "staff_r", you can sudo but still you're not as powerful as system administrator.

[2] To check your role, issue id -Z. For example, "root:sysadm_r:sysadm_t:s0-s15:c0.c1023" refers to the SELinux user "root" having the SELinux role "sysadm_r" and domain/type as "sysadm_t". The MLS range from s0 to s15 and authorized to compartment c0 till c1023.

[3] To change your role so that you gain different privileges, issue newrole -r {role}. For example, default role for root is "sysadm_r", you may switch to "secadm_r" as security admin by issuing newrole -r secadm_r.

[4] To adhoc switch between enforcing mode and permissive mode, you can edit the file /selinux/enforce.
- From permissive to enforcing: echo 1 > /selinux/enforce
- From enforcing to permissive: newrole -r secadm_r; echo 0 > /selinux/enforce; exit

In this trial, we are going to setup 2 files with different MLS level, 2 SELinux User with different MLS level, and to see if MLS policies apply correctly.

*Note: Carry the following as root and SELinux in permissive mode. semanage may not work fine in enforcing mode.

1. Creating users and specifies MLS levels for user

adduser alice
adduser bob
semanage user -a -L s1 -r s1:c0.c1023 -R user_r -P user s1_u
semanage user -a -L s2 -r s2:c0.c1023 -R user_r -P user s2_u
semanage login -a -s s1_u -r s1:c0.c1023 alice
semanage login -a -s s2_u -r s2:c0.c1023 bob

In case, Alice is assigned to SELinux user s1_u while Bob is assigned to s2_u. And, they are having different MLS levels. You need to set password for Alice and Bob by issuing passwd.

2. Creating files and apply security context to them

echo "This is file 1" > /file1
echo "This is file 2" > /file2
chmod 777 /file1
chmod 777 /file2
semanage fcontext -a -r s1 -s s1_u -t user_t /file1
semanage fcontext -a -r s2 -s s2_u -t user_t /file2
restorecon -v /file1
restorecon -v /file2

As SELinux policy first check DAC, chmod 777 allows the checking to be passed. Then set the security context to /file1 and /file2 respectively. /file1 belongs to MLS level s1 while /file2 belongs to MLS level s2. The last step is to restore the new context by issuing restorecon.

3. See what happen

First, switch SELinux into enforcing mode by issuing "echo 1 > /selinux/enforce". Do the following and see what happen.

(a) You're still login as root, try to cat /file1 and cat /file2. You probably get permission denied. You may issue ls -Z / and you may find "strange" thing like...

?---------    ?    ?                          file1
?---------    ?    ?                          file2

Even root is the owner of /file1 and /file2, root cannot access the files. This is because, by default, root is having MLS level s0 when login. By definition that can be viewed by semanage login -l, root can access levels from s0 to s15. To switch your MLS level to s15, issue newrole -l s15. Now, you can cat /file1 and /file2.

(b) Login as Alice, try to cat /file1 and cat /file2. You probably get content in /file1 but not in /file2. The reason is simple, user with MLS level s1 can access s1 objects but not objects in level s2. By Bell-La Padula model, you cannot read up ^^.

(c) Login as Bob, try to cat /file1 and cat /file2. You probably get content in both /file1 and /file2. By definition of Bell-La Padula model again, you can read down ^^.

(d) Try to write any stuff into /file1 or /file2 with any MLS level. You probably find that you get permission denied. The reason? SELinux MLS policy module is still "experimental" in FC11.