Multi-Category Security in SELinux in Fedora Core 5

# semanage user -a -P user -R user_r -L s0:c1 -r s0:c1-SystemHigh rjc
# semanage user -l

              Labeling  MLS/       MLS/
SELinux User  Prefix    MCS Level  MCS Range             SELinux Roles
rjc           user      s0:c1      s0:c1-SystemHigh      user_r
root          user      s0         SystemLow-SystemHigh  system_r
sysadm_r
+user_r
system_u      user      s0         SystemLow-SystemHigh  system_r
user_u        user      s0         SystemLow-SystemHigh  system_r
sysadm_r
+user_r

Fedora Core 5 uses the low end of the range for a process to specify the default context of files. The range parameter is specified by the -r switch. When using Fedora Core 5, often the only significant part of the range is the high end, which specifies the access. You should use the parameters -P user -R system_r when creating a user with the targeted policy (which is the default policy for a Fedora Core 5 install). The strict policy is much like the targeted policy in terms of MCS. Most of this article applies to the strict policy, although the -P and -R options to the semanage command will need different parameters.

After adding an identity, you must add a login entry to assign a UNIX account to the identity. The login configuration also allows you to specify the MCS range, because you may have many UNIX accounts with the same SELinux identity that have different MCS ranges assigned to them when they log in. You must use the -s parameter to specify the name of an SELinux identity that already exists. If you do not use the -r option to specify the range, it defaults to using no categories for the login entry in question (which may not be valid, depending on the low level of the range for the identity).

Below is an example of adding a login entry:

# semanage login -a -s rjc -r s0:c1-SystemHigh rjc
# semanage login -l

Login Name      SELinux User    MLS/MCS Range
__default__     user_u          s0
rjc             rjc             s0:c1-SystemHigh
root            root            SystemLow-SystemHigh

Note that the range for a login entry must be a subset of the range for an SELinux user identity. This means the low end of the login range must not be lower than the low end of the user identity range, and the high end of the login range must not be higher than the high end of the user identity range. In most cases, you will create a login entry with the same range as the user identity, so this won't be a problem.

After creating a file, it is possible to change the label to a different level with the chcon -l command. Below is an example of how to use it:

$ touch foo
$ ls -lZ foo
-rw-r--r--  rjc rjc rjc:object_r:tmp_t            foo
$ chcon -l s0:c0 foo
$ ls -lZ foo
-rw-r--r--  rjc rjc rjc:object_r:tmp_t:ProjectA   foo

Note that the level s0:c0 was translated to ProjectA; that is the translation I created previously.

It is possible to run a process with a different range. The following is an example of the use of the id -Z command to display the SELinux context (including the MCS range at the end) as well as the use of the runcon -l command to run an instance of bash in a different range:

$ id -Z
rjc:system_r:unconfined_t:SystemLow-SystemHigh
$ runcon -l s0-s0:c10.c20 bash
$ id -Z
rjc:system_r:unconfined_t:s0-s0:c10.c20
$ runcon -l s0-s0:c9.c20 bash
execvp: Permission denied

MLS was implemented in a flexible manner via the policy language. This allowed us to develop the MCS policy afterward using the same language features and also permits the development of other category- and level-based confidentiality controls without changing kernel code. One example of this is my new development, Mandatory MCS (MMCS).

A Mandatory Access Control (MAC) system is a system where the access control is determined by the system administrator and enforced by the operating system. Users are not permitted to override this access control by granting excess access to their own data files. In UNIX permissions, it is possible to create a mode 777 file in the /tmp directory that grants full access to all users. With MMCS, I wanted to prevent such access being granted. In the MMCS policy, it is not permitted to write to a file with a level below the low level of the process. This means that by setting the low levels for a user, the administrator can determine the minimum access needed to read files created by that user.

MCS and MLS policies have several significant differences. In MLS, the access is based on the low level of the range (the effective clearance) with the high level of the range used mostly to determine the access via the newrole program. In MCS, the access for both reading and writing is based on the high level of the range with the low level used only for restricting write access. Another difference is that MCS is designed to protect only the contents of files, while MLS restricts all methods of data transfer. Another major difference is that in MCS, a process may launch a child with a different range with minimal restrictions.