Abstract:

MCS (Multi-Category Security) is the latest development in SE Linux policy. It uses some of the features of MLS (Multi-Level Security) to provide extra protection.

MLS is based on sensitivity levels and categories. In MCS there is only one sensitivity level so therefore levels do not matter. Categories are the only part of MLS that is used. MCS is currently implemented on both the "strict" and "targeted" policies for SE Linux.

This paper describes the basic concepts of MLS, the design of MCS, and some of the implementation details.

MLS levels:

MLS (reference 1) is a MAC (Mandatory Access Control) system. This means that the access controls are enforced by the system and the user does not have discretion to avoid using them. DAC (Discretionary Access Control) is a system whereby each process can determine the access to be granted to each object it creates, for example a process can create a file in /tmp and give it mode 0777 to grant full access to all other users. Most mass-market operating systems implement DAC at best and have no support for MAC.

The primary characteristic of MLS is that it has multiple security levels. These are often named Top Secret, Secret, Classified, and Unclassified. There is no technical requirement that there be four levels (there could be more or fewer), or that those names be used. In a MLS system the primary aim is to prevent "read up" or "write down". "Read up" means reading data that is classified at a level higher than the process that is reading it, for example a process which has a clearance level of Secret can not read data from a file classified at the level of Top Secret. "Write down" means writing data into a level lower than the process that is writing it, for example a process which has a clearance of Secret writing to a file classified as Unclassified. Preventing "read up" and "write down" means that both intentional release of secret data to processes/people that lack appropriate clearance and accidental release via trojan horse programs is prevented.

It is permitted to "write up" and "read down". In practice this means that a document can be written at a Top Secret classification which is based on data from Secret, Classified, and Unclassified categories. Also a process running at Unclassified level could write to a file classified as Top Secret.

There is another issue of integrity which is addressed in SE Linux by using the domain-type model. Also a MLS system may rely on DAC to prevent unauthorised programs at a low clearance level from writing to highly classified files. MLS is generally not used for integrity of data. Trusted Irix contains a MLS integrity implementation (reference 2), but this has not been implemented in SE Linux and is very complex so I won't describe it.

MLS Categories:

Levels are not adequate to fully describe the security needs of military agencies or the computer systems that they use. It is common that people will not be permitted to read data that is at a classification level that they have clearance for but is in a different area (project, organization, etc). To implement this the MLS model includes a feature known as Categories. Every process in the MLS model has a clearance that includes zero or more categories. Each file that may be accessed will have a classification which also includes zero or more categories. If the set of categories for which the process is cleared is not a super-set of the categories with which the file is classified then the file can not be read.

In a commercial environment you might have categories for each NDA agreement that you sign with another company, for each secret research and development project, and for information that can't be released due to insider trading laws.

SE Linux Implementation of MLS

SE Linux provides a MAC system that is a second layer of defense, Unix permissions are the first line of defense. So you may have multiple users who have the same SE Linux security context who keep their data secret from each other through Unix permissions.

The primary feature of SE Linux is the domain-type model. In this model every process (subject) has a domain associated with it and every object that a process may access has a type associated with it. At the core of SE Linux is a database which describes for every combination of domain and type the access that is to be granted at a fine granularity (reference 4). For example file access is divided into create ioctl read getattr lock write setattr append link unlink rename.

Until recently the vast majority of SE Linux users did not use the MLS features. The most popular implementation of SE Linux has been in the Red Hat distributions, Fedora Core and Red Hat Enterprise Linux. In Fedora we have two policies, strict and targeted. The strict policy aims to grant minimal privileges to each process while the targeted policy has a domain named unconfined_t that has no restrictions and runs all programs from login sessions in that domain (references 5 and 6). The targeted policy aims to reduce the cost (in terms of administration work) of using SE Linux as much as possible.

The design of MCS:

MCS is an extension to both the strict and targeted policies which was mostly designed for the targeted policy. It aim is to allow categorising data without increasing the difficulty of system administration. The full MLS model requires some significant changes to typical Unix administration practices, the feature of preventing "read up" and "write down" is in stark contrast to the Unix tradition whereby highly privileged (root) processes can do everything that they want to less privileged processes and resources.

To avoid the full cost of MLS it was decided that levels would not be used. The SE Linux design permits using a policy that has no reference to MLS (no levels or categories defined) which has been commonly used in the past. However there is no support for a policy without levels but only categories, so for MCS we just define a policy with only a single level. The level is named s0 (for a MLS SE Linux policy the default configuration is to have sensitivity levels named s0 s1 s2 s3 s4 s5 s6 s7 s8 s9).

When labelling files and directories on disk each file system object has an XATTR named security.selinux that contains the security context for the object. If an object has a security context which does not match the policy which is in use then it is given the type unlabeled_t which prevents access to all processes other than those run by the system administrator. In the previous versions of the SE Linux kernel code if a file had a security context without the MLS components then it would get the type unlabeled_t which made an upgrade from a non-MLS system to MLS more difficult than necessary. A recent change in the kernel code assigns a default sensitivity level to such files. So when upgrading a machine to the MCS policy all files will have level s0 and no categories which is exactly what we desire for an initial MCS installation.

Integrating MCS into a distribution:

Supporting MCS in a distribution requires a lot more work than just adding it to the policy. It has to be possible to manage the labelling of files and processes in a manner that's not overly difficult. The basic support for changing the security contexts of files and preserving the context when copying files and backing them up has been in Fedora since Fedora Core 2. One of the issues with MLS is that only certain combinations of categories may make sense. So we need to have a method of translating MLS contexts to a human readable form. In rawhide we currently use the file /etc/mcs.conf to store translations from MLS labels to human readable labels, below is an extract from the default file:

# s0:c0=CompanyConfidential
# s0:c1=PatientRecord
# s0:c2=Unclassified
# s0:c3=TopSecret
# s0:c1,c3=CompanyConfidentialRedHat
s0=
s0-s0:c0.c127=SystemLow-SystemHigh

If the comment characters are removed then this means that category c0 maps to CompanyConfidential and the combination of categories c0 and c3 maps to CompanyConfidentialRedHat. With the current implementation a combination of the categories c0 and c1 will not be translated, a translation is only applied if there is an exact match from the MLS context to an entry in the mcs.conf file. This mapping is used by programs such as ls to display the context of files when the -Z option is used to display SE Linux contexts:

# ls -laZ
drwx------  rjc      rjc      rjc:object_r:staff_tmp_t:SystemHigh .
drwxrwxrwt  root     root     system_u:object_r:tmp_t          ..
-rw-rw-r--  rjc      rjc      rjc:object_r:staff_tmp_t         foo
# ls -la
total 32
drwx------   2 rjc  rjc  16384 Sep 28 17:05 .
drwxrwxrwt  15 root root  4096 Sep 28 17:22 ..
-rw-rw-r--   1 rjc  rjc      0 Sep 28 17:05 foo

In the above example you can see that the directory in question has the level s0 and the categories c0 to c127 inclusive.

Below is an example of the output of the id command:

# id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:sysadm_r:sysadm_t:SystemLow-SystemHigh

The above output shows that the clearance of the current process is s0-s0:c0.c127.

Further development of MCS/MLS:

The MCS policy not only provides the benefits stated previously but also facilitates further development of the MLS features of SE Linux. Prior to the release of MCS hardly anyone was using the MLS features which meant that numerous usability issues were not being addressed. The release of MCS means that many organizations which would not consider a full MLS implementation will now be using MLS features - and expecting them to work correctly! This of course means that software developers (people who work for the distributions of Linux, "upstream" free-software developers, and commercial application programmers) will be compelled to make their software work in an MLS environment. This addresses the greatest problem that has faced commercial use of MLS systems, the fact that almost no software was written specifically to support it and most of the software failed to work in some way when used on an MLS system.

When the MCS policy is widely released (Fedora Core 5 and Red Hat Enterprise Linux 5) it will be quite easy to convert an FC5 or RHEL5 machine to the full MLS policy. NB The full MLS policy will not be covered by the standard Enterprise Linux support contract.

The full MLS policy is designed to fulfill the requirements for certification under the Labeled Security Protection Profile (LSPP) (see reference 7). Certification is a long process, merely having MLS support is far from enough to get certification.

Future areas of work:

Future ideas include SE Linux support in a database server (per-row security contexts), SE Linux support in a mail server (which is more suitable to MLS than the domain-type model), and labeled printing (where every print job gets a header to indicate the classification of the document and the print server may decline to send some jobs to printers regarded as insecure).

For more information see references 8 and 9.

References:

1) Paper by Dr. Rick Smith on MLS: http://www.cs.stthomas.edu/faculty/resmith/r/mls/index.html

2) SGI MLS in Trusted Irix overview: http://www.sgi.com/pdfs/3241.pdf

3) The Inevitability of Failure by Peter A. Loscocco, Stephen D. Smalley, Patrick A. Muckelbauer, Ruth C. Taylor, S. Jeff Turner, John F. Farrell. Description of the concepts of the domain-type model and the reasons that it is necessary: http://www.nsa.gov/selinux/papers/inevitability/

4) Configuring the SELinux Policy by Stephen Smalley: http://www.nsa.gov/selinux/papers/policy2-abs.cfm

5) What's New in Fedora Core 3 SE Linux (a description of the Targeted policy) by Faye Coker: http://www.linuxjournal.com/node/7887

6) Taking advantage of SELinux in Red Hat Enterprise Linux (includes detail on the Targeted policy) by Russell Coker and Faye Coker: http://www.redhat.com/magazine/006apr05/features/selinux/ James Morris BLOG entry giving an overview of MLS: http://www.livejournal.com/users/james_morris/5020.html

7) LSPP description: http://niap.nist.gov/cc-scheme/pp/PP_LSPP_V1.b.pdf

8) James Morris BLOG entry: http://www.livejournal.com/users/james_morris/5583.html

9) My SE Linux play machine running MCS (online as of the time of the conference, not always online): http://www.coker.com.au/selinux/play.html