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.
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.
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.
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.
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.
# s0:c0=CompanyConfidential # s0:c1=PatientRecord # s0:c2=Unclassified # s0:c3=TopSecret # s0:c1,c3=CompanyConfidentialRedHat s0= s0-s0:c0.c127=SystemLow-SystemHighIf 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 fooIn 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-SystemHighThe above output shows that the clearance of the current process is s0-s0:c0.c127.
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.
For more information see references 8 and 9.
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