Multi categories security
|This article does not cite any sources. (October 2007) (Learn how and when to remove this template message)|
Multi Categories Security (MCS) is an access control method in Security-Enhanced Linux that uses categories attached to objects (files) and granted to subjects (processes, …) at the operating system level. The current implementation in Fedora Core 5 is advisory because there is nothing stopping a process from increasing its access. The eventual aim is to make MCS a hierarchical mandatory access control system. Currently, MCS controls access to files and to ptrace or kill processes. It has not yet decided what level of control it should have over access to directories and other file system objects. It is still evolving.
MCS access controls are applied after the Domain-Type access controls and after regular DAC (Unix permissions). In the default policy, it is possible to manage up to 256 categories (c0 to c255). It is possible to recompile the policy with a much larger number of categories if required.
As part of the Multi-Level Security (MLS) development work applications such as the CUPs print server will understand the MLS sensitivity labels, CUPs will use them to control printing and to label the printed pages according to their sensitivity level. The MCS data is stored and manipulated in the same way as MLS data, therefore any program which is modified for MCS support will also be expected to support MLS. This will increase the number of applications supporting MLS and therefore make it easier to run MLS (which is one of the reasons for developing MCS).
Note that MCS is not a sub-set of MLS, the Bell–LaPadula model is not applied. If a process has a clearance that dominates the classification of a file then it gets both read and write access. For example in a commercial environment you might use categories to map to data from different departments. So you could have c0 for HR data and c1 for Financial data. If a user is running with categories c0 and c1 then they can read HR data and write it to a file labeled for Financial data. In a corporate environment this is usually regarded as acceptable, if a user is trusted with both HR and Financial access then their integrity and skills are trusted to ensure that the data is not mistakenly released to the wrong file. For secret military data this is regarded as unacceptable and the Bell–LaPadula model prevents such accidental or malicious relabeling of data.