Previously, I posted a brief introduction to Multi-Category Security (MCS), outlining its rationale and design. Since then, work has continued on integrating MCS into Fedora for FC5, along with some other recent developments such as modular policy support and a comprehensive management framework.

We can now take a practical look at MCS, covering basic administration and use. Currently, you’ll need to be running Fedora Core rawhide to ensure that all of the latest libraries and utilities are present on the system. Check that you have at least policycoreutils-1.29.8-4.

Overview
As discussed in my previous post on the topic, MCS allows users to assign categories to their own files. These categories are simply text labels, such as “Company_Confidential” or “Medical_Records”. The sysadmin first configures the categories, then assigns users to them as required.

So, jose might be assigned to categories “Marketing” and “Payroll”, while lara is assigned to “Finance”. The names of the categories and their meanings are set by the sysadmin, and can be set to whatever is required for the specific deployment. A system at home may simply have one category of “Private”, and be configured so that only trusted local users are assigned to this category.

Once users are assigned to categories, they may label any of their own files with any of their categories. So, our home user, frobnoz can label all of her secret diary entries “Private”, and no service such as apache or vsftp will ever be able to access such files, as they don’t have access to the “Private” category.

In a corporate environment, categories could be used to identify documents confidential to specific departments, or being covered under certain NDAs. So, when jose prepares a report on payroll statistics for the month, he can label it as “Payroll”, which will not be accessible by lara, who only has access to the “Finance” category.

It’s a very simple system: to access a file, a user needs to be assigned to all of the categories with which the file is labeled.

The MCS check is applied after normal Unix DAC and Type Enforcement rules, so it can only further restrict security.

Terminology
Before moving onto practical matters, we need to clarify a couple of MCS/SELinux specific terms.

SELinux maintains its own user identity for processes, separately from Unix user identities. With targeted policy (the default for Fedora and RHEL), there are only a few SELinux user identities:

system_u	System processes
root	System administrator
user_u	All login users

SELinux users can be viewed with the semanage(8) utility:

# semanage user -l

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

root            s0         SystemLow-SystemHigh           system_r sysadm_r user_r
system_u        s0         SystemLow-SystemHigh           system_r
user_u          s0         SystemLow-SystemHigh           system_r sysadm_r user_r

One of the properties of targeted policy is that login users all run in the same security context. From a TE point of view, in targeted policy, they are security-equivalent. However, for MCS, we need to be able to assign different sets of categories to different Unix users, even though they are all the same SELinux user (user_u above). This is solved by introducing the concept of an SELinux login, which is simply used during the login process to assign MCS categories to Unix users when their shell is launched.

SELinux logins can also be viewed with semanage(8):

# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               user_u                    s0                       
fred                      user_u                    s0-Marketing,Payroll,NDA_Yoyodyne
jose                      user_u                    s0-Marketing             
lara                      user_u                    s0-Payroll,NDA_Yoyodyne,Company_Confidential,Marketing
root                      root                      SystemLow-SystemHigh

This also shows the mapping of SELinux logins to MCS categories. The “s0” values are MLS sensitivity levels, which we ignore in MCS. In this example, we can see that fred has access to the categories “Marketing”, “Payroll” and “NDA_Yoyodyne”. Unix users with no SELinux login are assigned to the default set of categories, which in this case is empty. root has access to all categories. Rather than display every possible category here, the alias “SystemLow-SystemHigh” is used, which means every possible security level from the lowest to the highest on the system.

Now that we’ve covered SELinux users and SELinux logins, we can really get started.

Configuring Categories
The first thing the sysadmin will want to do with MCS is configure some categories. This is carried out by editing /etc/selinux/targeted/setrans.conf, a file which specifies how the internal MLS sensitivities and categories are to be translated for human use. As discussed in the previous post, SELinux has an internal representation of MLS/MCS labels. For categories, they are of the abstract form c0, c1, … c255. Meaning that up to 256 separate categories can be used on the system.

The setrans.conf file contains mappings from internal labels to external values.

Here’s how the file looks by default:

s0=
s0-s0:c0.c255=SystemLow-SystemHigh
s0:c0.c255=SystemHigh

On the left of the equals sign is the MLS/MCS security level, while the human-readable value is on the right. The “s0” is the dummy MLS sensitivity level. On the first line “s0=” means to simply display nothing when there are no categories. This also hides the dummy “s0”.

The next two lines simply add aliases for some common cases, to suppress displaying all 256 categories if a user (such as root) is assigned to all of them. Note the syntax for specifying a range of categories: “c0.c4” means all categories from “c0” through “c4”. This can also be represented as “c0,c1,c2,c3,c4”.

Now, let’s add a some categories:

s0:c0=Company_Confidential
s0:c1=Marketing
s0:c2=Payroll
s0:c3=NDA_Yoyodyne

This simply maps “c0” to “Company_Confidential”, and so on. Once saved, these categories have been configured for use.

To get a handy listing of categories, use the chcat(8) utility:

# chcat -L
s0                             
s0-s0:c0.c255                  SystemLow-SystemHigh
s0:c0.c255                     SystemHigh
s0:c0                          Company_Confidential
s0:c1                          Marketing
s0:c2                          Payroll
s0:c3                          NDA_Yoyodyne

Labeling Files
As root, you can now start labeling files with MCS categories (because the SELinux login for root has access to all of them). Start with a file with no MCS category label:

# cd /tmp
# echo "This is a test file" > testfile.txt
# ls -Z testfile.txt 
-rw-r--r--  root     root     root:object_r:tmp_t              testfile.txt

This shows the standard SELinux security context assigned to the file by the kernel upon creation. The setrans.conf file is actually hiding the “s0” sensitivity level. You can disable this translation completely at any time by adding the following line to setrans.conf:

disable=1

Now, let’s have a look at the file listing again:

# ls -Z testfile.txt 
-rw-r--r--  root     root     root:object_r:tmp_t:s0           testfile.txt

Enable translation again by commenting the “disable=1” line out:

#disable=1

Here’s how to add an MCS category to the file:

# chcat --   +Marketing testfile.txt

(The ‘–‘ is used to indicate that any options to chcat have finished).

Now, look at the file listing:

[root@xeon tmp]# ls -Z testfile.txt 
-rw-r--r--  root     root     root:object_r:tmp_t:Marketing    testfile.txt

The security context now has an extra field, “Marketing”. This is an MCS category. We can add another:

# chcat --   +Payroll testfile.txt

And we should now see the file labeled with both categories:

# ls -Z testfile.txt 
-rw-r--r--  root     root     root:object_r:tmp_t:Marketing,Payroll testfile.txt

You can arbitrarily add and delete category labels:

# chcat --  +NDA_Yoyodyne,-Marketing,-Payroll testfile.txt
# ls -Z testfile.txt
# -rw-r--r--  root     root     root:object_r:tmp_t:NDA_Yoyodyne testfile.txt

To delete all categories (handy if there are more than one), use chcat -d.

Assigning Categories to Users
In these examples, three Unix users have been added to the system: andre, martina and venus. Initially, they’re all associated with the default SELinux login, with root configured for all categories by the installer:

# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               user_u                    s0                       
root                      root                      SystemLow-SystemHigh

On this system, we’ll say that andre is in the Marketing department, and martina is in the Payroll department. venus is a senior executive with access to all of the important information in the company. To allow these users to be distinguished by MCS, they need to be mapped to SELinux logins:

# semanage login -a andre
# semanage login -a martina
# semanage login -a venus
# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               user_u                    s0                       
andre                     user_u                    s0                       
martina                   user_u                    s0                       
root                      root                      SystemLow-SystemHigh     
venus                     user_u                    s0

As you can see, these users are now configured with SELinux logins, with no MCS categories assigned.

To assign MCS categories to these logins, use chcat(8), with the ‘-l’ parameter to specify a login object instead of a file:

# chcat -l --  +Marketing andre
# chcat -l --  +Payroll martina
# chcat -l --  +Payroll,+Marketing,+NDA_Yoyodyne venus
# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               user_u                    s0                       
andre                     user_u                    s0-Marketing             
martina                   user_u                    s0-Payroll               
root                      root                      SystemLow-SystemHigh     
venus                     user_u                    s0-Payroll,Marketing,NDA_Yoyodyne

You can also get a simpler listing of which categories a user has with the ‘-L’ option to chcat(8):

# chcat -L -l andre martina venus
andre: Marketing
martina: Payroll
venus: Payroll,Marketing,NDA_Yoyodyne

Note that as MCS category access is assigned during login, a user will not have access to the categories until they login again. Similarly, if access to a category is revoked, this will only be apparent to the user after the next login.

Using Categories
With MCS categories now configured, and users assigned, we can look at a simple usage example.

andre is working on a new marketing strategy, and due to corporate policy, only members of the marketing department and some executives are allowed to know the details at this stage. He can use MCS to label any files containing information about the new strategy as follows:

$ chcat --  +Marketing andre_strategy.txt
$ ls -Z andre_strategy.txt
-rw-rw-r--  andre    andre    user_u:object_r:tmp_t:Marketing  andre_strategy.txt

This is just an example of how to use MCS: of course, you wouldn’t normally expect someone from marketing to work with such low level tools (then again, who knows). Integrating MCS labeling support into high-level apps such as editors is a near-tearm goal, and should be fairly straightforward. Anyway, now that the file is labeled with this MCS category, only users assigned to that category can access it, assuming that Unix DAC and SELinux TE permissions would already allow the access. Let’s see what happens when martina tries to read the file:

$ cat andre_strategy.txt 
cat: andre_strategy.txt: Permission denied

Note that the unix DAC permissions would have allowed this. But, venus should be able to access the file, as she has access to the category it’s labeled with:

$ cat andre_strategy.txt 
No idea, help...

Summary
MCS labeling from a user and sysadmin standpoint is very simple, although as a new technology, there are a few new things to learn. In a nutshell, it’s a matter of configuring a set of categories then assigning users access to them. The users can then use the labels as they see fit, including discretionary compliance with corporate security and other policies, which maps to the way such policies are generally implemented. For example, in a corporate environment, you may be given an NDA-covered document with handling instructions which you are required to follow. Exactly how you comply with such policies is often left up to common sense or fairly general procedural guidelines. MCS should map to this kind of thing much more readily than MLS, which is designed to map to very rigid military and government agency security policies and finely detailed procedures. MCS is more about providing a mechanism for complying with a wide range of policies and procedures, rather than hard-coding these policies into the code or even the defauult configuration.

As you can see, the basic tools and functionality exist, but more work is needed (and being done) on higher level tools and integration. A GUI tool from Dan Walsh should be available soon (it’s in internal testing), which will abstract much of this management away nicely. There’s a huge amount of work going on in the underlying SELinux management and deployment infrastructure, which will continue to bubble up into our management utilities and high-level apps.

Any questions on MCS, or if you want to dive in and work on something, contact the developers via the NSA SELinux mailing list or the Fedora SELinux mailing list.

Russell Coker will be giving a talk on MCS at the SELinux Symposium in Feb/Mar, Baltimore. We’re also hoping to have some form of discussion with users and interested parties, as MCS is a new and evolving technology.

The delegates were supposed to be announced today, but there’ll be a delay on this for a few days due in part to weather affecting travel for some involved in the project.

(SELinux Symposium Community Delegate Program).

I’m back now, after a truly wonderful time in Bangalore. It seems to me that FOSS.IN/2005 was a major success by several measures: number of delegates, speakers, tutorials, BoFS, talks; the amount of local buzz (overshadowing an official IT industry conference to the point where the government sent people to see what was going on), and the global reach. This conference had the best atmosphere of any that I’d attended (it’s tough to beat something like LCA in Perth), and it was genuinely enjoyable. Apart from all of the official talks and events, if you looked around the grounds (many photos are linked from the web site), you saw something very important: people in small groups, talking. Often passionate discussions around all kinds of technical and cultural issues relating to FOSS. It felt like the kind of excitement experienced in the early days of Linux. The possibilities, the challenges, the potential. And most importantly, the fun.

There was much talk of how India needed to learn about FOSS culture. Currently, there are a lot of device driver developers, for example, who may not have internet access at home and have severe limitations imposed by their employers on how much they can contribute openly. These kinds of issues are problematic, for now. But after thinking more generally during the trip back, I’ve come to see that this FOSS cultural exchange needs to be bi-directional. Not just people from established western free software communities coming in and brain dumping. This is of course important, but only half the picture.

As witnessed by the fact that this conference exists at all, unifying LUGs from across such a vast country, India already has significant FOSS culture. Some aspects of it are uniquely Indian. The general FOSS community has a lot to learn from India. Similarly, there are strong FOSS communities in Japan, often different in nature to those in the west. The incorporation of USAGI (IPv6 and IPSec) technology into the kernel is an existing example of how these sometimes separate FOSS cultures can successfully engage with each other.

I think this is one of the exciting challenges for FOSS in the near and long term future: figuring out how to engage, foster and learn from FOSS communities outside of the traditional western-oriented core. And like countries where many cultures exist together successfully, the global FOSS community stands to benefit from the diversity, and in fact to significantly evolve because of it.

I’d strongly recommend international FOSS developers consider submitting talks for the next conference (I gather there will be one), as it’s a) a blast; b) a great opportunity to spread your knowledge widely and; c) a great forum for learning about FOSS in a wider cultural context.

Anyway, enough rambling. Here are a few more photos (I’ll try and put more up via Gallery or something eventually).

Atul Chitnis, whose determination and vision made it happen.

Alan Cox’s kernel hacking talk on the last day, with the main hall packed and delegates intensely focused. This might be a record for the number of people attending a kernel hacking talk. Certainly for people actually taking notice of such a talk. Jon Corbet and Harald Welte also packed out the hall that day with talks on a similar level.

All-day food BoF adjoining the kitchens. This is where a lot of the real action happened each day.

Here’s a few photos from the conference.

Volunteers working the registration booth, welcoming three thousand or so delegates.

Delegates walking between the halls (which were constructed for the event in the Bangalore Palace gardens).

Entrance to Sulamita Garcia’s Linuxchix talk, which was held in the ballroom of the palace. There seems to be a higher percentage of female delegates here than other technical conferences I’ve attended.

Harald Welte and Jaya Kumar chatting to delegates.

Here are the slides from my FOSS.IN/2005 talks.

• Overview of NSA Security Enhanced Linux (pdf)
• SELinux Kernel Internals and Architecture (pdf)

Also, found some good media coverage here in The Hindu.

Bangalore: The grounds of the Bangalore Palace have seen many high tech conferences — including the annual IT.in mela — but nothing like this: On Tuesday nearly 3000 young `techies’ queued up for over an hour to register for `FOSS.in’, the annual Free and Open Source Software conference which began five years ago as the Bangalore Linux event.

The atmosphere here is fantastic. It’s currently a very bright and warm day with a nice dry breeze. People are wandering around the grounds of the Bangalore Palace, sitting under trees, chatting, eating lunch. All of the technical talks I’ve seen so far have been packed. I can’t remember another conference with so much enthusiasm and such intense thirst for knowledge. It seems like there’s a looming explosion in grassroots Linux activity here (consider the fact that this huge conference itself is a volunteer effort).

I’m now in Bangalore for FOSS.IN/2005, which looks to be a very large event this year with several thousand delegates expected. Wandered around the city today with a few other speakers, and found lots of Linux books and distros available on store shelves.

(Rs. 450 is about USD $10).

There’s just over two weeks left to nominate for the SELiunx Symposium Community Delegate Program. If you know someone making important community-based contributions to SELinux, nominate them per the link and they may be selected to travel to the 2006 SELinux Symposium in Baltimore, Maryland. Remember that you can self-nominate, and that nominations are open worldwide.

I’ll be giving two SELinux talks at FOSS.IN/2005 in a couple of weeks. One on kernel internals and architecture, and another on developments in SELinux. So far, there are 185 events scheduled overall with around 3000 people expected to attend. I’ve never seen a technical Linux/FOSS conference on this scale.

Reduced memory footprint
The 2.6.14 kernel release has an important change in the way SELinux uses kernel memory.

Under SELinux, checkpolicy manipulates security policy entries into low-level access rules and compiles them into a binary format. The binary policy is then loaded into the kernel via writing to /selinux/load. During the load, these access rules are inserted kernel’s access vector table (avtab), which is later consulted for every SELinux access control check, with results cached in the access vector cache (AVC).

A typical security policy may contain tens or even hundreds of thousands of these low-level rules, and thus, require significant amounts of kernel memory to store them in the avtab. A patch from Stephen Smalley (here) was merged upstream during 2.6.14 development which dramatically reduces the memory used by the avtab. It first reduces the size of the data structures used to hold the access rule information, resulting in a ~50% reduction in the total size of the memory used. The total number of avtab nodes is also reduced, by essentially pre-computing less information. The latter theoretically imposes an additional runtime overhead, although any calculated results are stored in the AVC, and no significant performance hit has been measured.

This results in memory savings of up to around 20x, depending on the system architecture and policy configuration. I measured the number of avtab slab objects on a 64-bit system at the time (via “grep avtab_node /proc/slabinfo“):

            #objs  objsize   kernmem
Targeted policy:
  Before:  237888       40     9.1MB
  After:    19968       24     468KB

Strict policy:
  Before:  571680       40   21.81MB
  After:   221052       24    5.06MB

This shows a massive kernel memory saving for targeted policy, from over 9MB to 470KB. The avtab object size is reduced from 40 bytes to 24 (on 32-bit, it’s 32 bytes to 16), and the total number of entries is reduced by an order of magnitude. As well as the sheer reduction of kernel memory, having a smaller object size invokes other efficiencies such as increasing the number of objects per slab. Improvements for strict policy are not as large, but still significant. Given that the default is targeted policy, this is a very welcome outcome.

Generic security xattr handling
Another interesting patch (here), changes the VFS to punt security extended attribute calls to the loaded security module if the filesystem does not support them natively. This allows the security module to perform in-kernel labeling for all such filesystems, and for the removal of existing security xattr code for devpts and tmpfs (and the need to write similar code for other psuedo-filesystems). Under SELinux, this change means that security xattrs on pseudo-filesystems now “just work”. Calls to setxattr(2), getxattr(2) and listxattr(2) operate on in-kernel values automatically, and you’ll actually see security contexts now when doing things like:

# ls -Z /selinux/null 
crw-rw-rw-  root     root     system_u:object_r:null_device_t  /selinux/null

Atomic inode create and label
This patchset implements atomic inode labeling, ensuring that it is possible to create and label a file in an atomic operation. Previously, there was a gap during file creation where it was possible to access an inode before the labeling hook was invoked. This has always been safe under SELinux, due to inodes being created with a safe default label, although under heavy loads, you would sometimes see false denials caused by this default label being referenced. The security risk here was indirect: people may end up loosening their security policies to avoid the false denial messages. The patchset fixes the problem by adding a new LSM hook inode_init_security, to be called from within each security xattr supporting filesystem during file creation. Each of these filesystems has been modified to call the hook.

Miscellaneous
As well as minor fixes and the usual audit-related adjustments, there’s an update to the way IP protocol sockets are classified by SELinux, to correctly accommodate more recently implemented protocols such as SCTP and DCCP.

***

Also, there’s a month left to get nominations in for the SELinux Symposium Community Delegate Program. If you know someone (including yourself) who’s active in the SELinux community, and you think they deserve a free trip to Baltimore, be sure to nominate them before November 30th.

Red Hat and HP are sponsoring a delegate program for the 2006 SELinux Symposium in Baltimore, Maryland, USA.

Modeled somewhat on the Sun Regional Developer Program for LCA, the purpose of this program is to recognize and encourage community-based SELinux efforts. Up to three delegates will be chosen to attend the symposium, covering the costs of their travel, registration and accommodation.

If you know anyone who’s been doing good work on SELinux (including yourself), follow the link below and nominate them.

Note that this is not just for developers: any form of involvement, including helping out on mailing lists, documentation, academic research, user group efforts etc. is valid for nomination in this program. The closing date for nominations is November 30, 2005, so there’s still quite a bit of time.

Full details of the SELinux Symposium Delegate Program here.

If you update to the current Fedora rawhide now, you’ll be able to start using a new security mechanism called Multi-Category Security (MCS).

Rationale
MCS is something we’ve been working on to help make SELinux more user-oriented, as well as adapt some of the Multi-Level Security (MLS) infrastructure for more general use. An important aspect of SELinux is that it implements Mandatory Access Control (MAC), where security policy is managed by a system or security administrator and is not overridable by users or applications. MAC is important for dealing with security threats arising from software flaws, malware, user error and some classes of malicious users.

Unfortunately, a fine-grained, flexible MAC system is also likely to be complicated, reflecting the complexity of the underlying operating system. Currently, the idea is that a vendor (such as Fedora) ships the SELinux security policy, which may then be modified in a controlled and limited way by a system administrator via ‘booleans’. These are a set of high level abstractions which may be enabled or disabled as required, such as ‘httpd_enable_cgi’.

The vendor and the sysadmin thus have some say in the way security is imposed on this MAC system, but users have no real say over things. Which is generally what we want with MAC security, although as a technology, it doesn’t really empower or engage users. How can a MAC system allow users to have more direct control over security? The answer is pretty simple: provide a mechanism which allows users to further restrict the security of their own resources. This is what MCS does.

In a nutshell, MCS is an enhancement to SELinux which allows users to label files with categories. These categories are used to further constrain DAC and TE logic. They may also be used when displaying or printing files. An example of a category is “Company_Confidential”. Only users with access to this category can access files labeled with the category — assuming the existing DAC and TE rules also permit access.

The term categories here refers to the same non-hierarchical categories as used by MLS. I recently provided an overview of MLS and related concepts including categories here — it may be useful as a reference in understanding MCS. To briefly recap, under MLS, objects and subjects are labeled with Security Levels. These Security Levels consist of an hierarchical sensitivity value (such as “Top Secret”) and zero or more non-hierarchical categories (such as “Crypto”). Categories provide compartments within sensitivity levels and enforce the need to know security principle.

MCS is in fact an adaptation of MLS. It re-uses much of the MLS framework in SELinux, including the MLS label field, MLS kernel code, MLS policy constructs, labeled printing and label encoding/translation. From a technical point of view, MCS is a policy change, along with a few userland hacks to hide some of the unwanted MLS stuff. There are a couple of kernel changes, but only relating to making it easy to upgrade to MCS (or MLS) without invoking a full filesystem relabel.

Another important justification for MCS is that it will provide a way to more widely deploy, test and even shape the concurrent MLS development effort. Legacy MLS systems have often been an old, heavily modified fork of the main OS product. These ‘trusted’ systems tend to fall behind their general purpose counterparts by at least a release or two, and could be described as a series of evolutionary dead ends accompanied by expensive certificates. The userbase for these systems is likely to be very small and narrow, and the QA burden must be enormous (read: expensive, and passed on to the user). With MCS, we ‘re trying to avoid these problems to a large extent by including MLS technology in the current version of the OS and enabling a generally useful subset of it by default. We want this technology to be mainstream, as far as possible.

The hope is to improve the quality of the system as a whole, reduce costs, leverage the open source process, increase transparency, and make the technology base useful to more than a handful of extremely special case users.

Design
There are a few major differences between MCS and MLS:

1) MCS ignores sensitivity levels. Everything is labeled with the same sensitivity, ‘s0’, which makes the idea of sensitivity levels effectively disappear. Hierarchical security designations generally do not map well outside of Military and similar environments, which are rigidly defined and controlled.

2) MCS discards the Bell La-Padula (BLP) security model. BLP properties such as No-Write-Down, which is designed to prevent leakage from high security levels to low security levels, are often confusing and break many assumptions of existing software . Consider root not being able to write to /tmp, as one of many possible problems relating to shared data.

3) MCS is discretionary, similar to standard Unix DAC logic. The current implementation provide users with MCS control over their own files. This should map more readily to more general cases, reflecting the typical discretionary nature of real-world security outside of the Mil/Gov etc. environment. It is possible to adjust MCS to make it less discretionary, but really, that’s what MLS is for.

4) MCS always runs at a single level. The current level of all subjects running on the system is ‘s0’. When a subject is granted access to categories (remember: a security level is a combination of sensitivity and categories), this is done by adding categories to the high range clearance of the subject. The high range clearance refers to the maximum security level that the subject can run at. Under MCS, the subject will never run at anything other than ‘s0’, so the high range clearance is merely used to determine which categories the subject has access to when performing an access control decision. This is similar to Unix supplementary groups: a process can have access to several supplementary groups but not be running in any of them. Similarly, under MCS, a process can have access to a set of categories, but not be running at a security level which includes them. Having everything running at the same level vastly simplifies things.

MCS uses MLS technology, but is not MLS. This should be made very clear: MCS does not provide any inherent protection against flawed or malicious software, user error or malicious users. However, keep in mind that it sits on top of standard Type Enforcement (TE), which is a MAC scheme. Both traditional DAC and TE rules are consulted before MCS rules.

So, a user might create a file and label it with the category “Company_Confidential”. Only processes with access to that category will then be able to access the file. Apache, for example, would not be able to read the labeled file, unless it was itself cleared to access the “Company_Confidential” category.

The names of the categories are set by the sysadmin, who also determines which users have access to which categories. Internally, SELinux sees all categories in the form Cn (C0…C127). A translation file, /etc/mcs.conf, may be edited by the sysadmin to assign locally meaningful values to categories. The intent here is to allow maximum flexibility when deploying systems.

Categories could be names of departments, such as “Finance” and “Payroll”; they might refer to the nature of the information and be linked to business rules for information handling, such as “Patient_Data” or “Credit_Card_Details”; they could also indicate that the information is associated with specific NDAs like “NDA-GOV-12338310A”. It’s really up to users how they make use of MCS and integrate it with their business rules.

You may realize by now that MCS seems like ACLs. MCS is similar, but not equivalent to ACLs. For detailed discussion on the subject, refer to this thread on the SELinux mailing list.

Use
Beyond access control, one planned use of MCS is to re-use MLS labeled printing, so that the MCS categories can be displayed at the top and bottom of each page being printed, and/or on a cover sheet which may also indicate handling procedures for the document. It should also be possible to integrate MCS with future developments in SELinux, such as Security Enhanced X. If integrated with a directory server, it may be possible to add MCS support to email, so that outgoing emails can be labeled by the sender and also through the act of attaching labeled files. The mailer can then determine whether the recipients are known to be cleared to access the categories assocated with the emails.

Currently, MCS is in an early but useable and seemingly stable stage of development. As mentioned, upgrading to the latest Fedora rawhide will install the updated policy and userland components. If you want to activate MCS, you will need to reboot your system (sorry). This is absolutely required as SELinux has to be restarted with MLS subsystem active, which can only be done securely during early kernel initialization. You should not need to relabel your filesystem, even though the label format on disk has changed. Pre-MCS files contexts will be interpreted automatically by the kernel as MCS contexts. Newly created files under MCS will, however, be labeled with the extra ‘MLS’ field:

$ touch foo
$ ls -Z
-rw-r--r--  fred     fred     user_u:object_r:tmp_t:s0           foo

Note the ‘s0’ on the end. This is the dummy sensitivity level with which everything is labeled under MCS. Normally, this component will be hidden, as it is not useful under MCS. In this case, the field was un-hidden by editing /etc/mcs.conf and adding a line:

disable=1

Setting that to zero again will enable the label translation library.

$ ls -Z
rw-r--r--  fred     fred     user_u:object_r:tmp_t               foo

With the dummy sensitivity level hidden, the system, by default will act as if nothing has changed. Only when categories are added to files should behavior change.

Currently, it is always still possible to see the ‘real’ label on the file with getfattr(1), which calls getxattr(2) directly without using the label translation library.

$ getfattr -n security.selinux foo
# file: foo
security.selinux="user_u:object_r:tmp_t:s0\000"

This is expected to change in the 2.6.15 kernel (and already has in the latest -mm kernels), so that getxattr(2) always returns the kernel’s canonicalized version of the label. This is to simplify the userland code, which is currently jumping through some flaming hoops to manage different label formats.

Adding a category to a file is currently performed via chcon(1):

$ chcon -l Moonbase_Plans foo

$ ls -Z foo
-rw-r--r--  fred     fred     user_u:object_r:tmp_t:Moonbase_Plans foo

Note that the category label is in the MLS field of the security context. The value of the label was configured in /etc/mcs.conf for this example.

s0:c10=Moonbase_Plans

Which means: c10 is to be translated to “Moonbase_Plans”, where c10 is one of the generic categories used internally by SELinux. Now, domains without access to this category will not be able to access the file.

Note that you can view the internal category value (c10) as part of the raw MLS field using gefattr(1) or disabling label translation (as mentioned above).

$ getfattr -n security.selinux foo
# file: foo
security.selinux="user_u:object_r:tmp_t:s0:c10\000"

Status
In this initial release, by default, all SELinux users are provided with access to all categories (c0 through c127). This can of course be locally customized by the sysadmin, but the primary intention at this stage is to enable the technology and get people using it.

Work is being done on a flexible user management scheme, where individual users at the Unix level are assigned a set of categories during login. This is to prevent the need for manipulating SELinux user policy and policy reloads.

Join the NSA SELinux mailing list if you’re interested in discussing and/or using MCS as we develop it further.

A special thanks to Dan Walsh who did a lot of heavy lifting getting some of the tricky userland MCS stuff working. It’s quite a feat to enable a new security model in a mainstream general purpose operating system without causing a great deal of disruption.