第 6 章 Using Multi-Level Security (MLS)


The Multi-Level Security (MLS) policy uses levels of clearance as originally designed by the US defense community. MLS meets a very narrow set of security requirements based on information management in rigidly controlled environments such as the military.

Using MLS is complex and does not map well to general use-case scenarios.

6.1. Multi-Level Security (MLS)

The Multi-Level Security (MLS) technology classifies data in a hierarchical classification using information security levels, for example:

  • [lowest] Unclassified
  • [low] Confidential
  • [high] Secret
  • [highest] Top secret

By default, the MLS SELinux policy uses 16 sensitivity levels:

  • s0 is the least sensitive.
  • s15 is the most sensitive.

MLS uses specific terminology to address sensitivity levels:

  • Users and processes are called subjects, whose sensitivity level is called clearance.
  • Files, devices, and other passive components of the system are called objects, whose sensitivity level is called classification.

To implement MLS, SELinux uses the Bell-La Padula Model (BLP) model. This model specifies how information can flow within the system based on labels attached to each subject and object.

The basic principle of BLP is "No read up, no write down." This means that users can only read files at their own sensitivity level and lower, and data can flow only from lower levels to higher levels, and never the reverse.

The MLS SELinux policy, which is the implementation of MLS on RHEL, applies a modified principle called Bell-La Padula with write equality. This means that users can read files at their own sensitivity level and lower, but can write only at exactly their own level. This prevents, for example, low-clearance users from writing content into top-secret files.

For example, by default, a user with clearance level s2:

  • Can read files with sensitivity levels s0, s1, and s2.
  • Cannot read files with sensitivity level s3 and higher.
  • Can modify files with sensitivity level of exactly s2.
  • Cannot modify files with sensitivity level other than s2.
注意

Security administrators can adjust this behavior by modifying the system’s SELinux policy. For example, they can allow users to modify files at lower levels, which increases the file’s sensitivity level to the user’s clearance level.

In practice, users are typically assigned to a range of clearance levels, for example s1-s2. A user can read files with sensitivity levels lower than the user’s maximum level, and write to any files within that range.

For example, by default, a user with a clearance range s1-s2:

  • Can read files with sensitivity levels s0 and s1.
  • Cannot read files with sensitivity level s2 and higher.
  • Can modify files with sensitivity level s1.
  • Cannot modify files with sensitivity level other than s1.
  • Can change own clearance level to s2.

The security context for a non-privileged user in an MLS environment is, for example:

user_u:user_r:user_t:s1

Where:

user_u
Is the SELinux user.
user_r
Is the SELinux role.
user_t
Is the SELinux type.
s1
Is the range of MLS sensitivity levels.

The system always combines MLS access rules with conventional file access permissions. For example, if a user with a security level of "Secret" uses Discretionary Access Control (DAC) to block access to a file by other users, even "Top Secret" users cannot access that file. A high security clearance does not automatically permit a user to browse the entire file system.

Users with top-level clearances do not automatically acquire administrative rights on multi-level systems. While they might have access to all sensitive information about the system, this is different from having administrative rights.

In addition, administrative rights do not provide access to sensitive information. For example, even when someone logs in as root, they still cannot read top-secret information.

You can further adjust access within an MLS system by using categories. With Multi-Category Security (MCS), you can define categories such as projects or departments, and users will only be allowed to access files in the categories to which they are assigned. For additional information, see Using Multi-Category Security (MCS) for data confidentiality.

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2026 Red Hat
返回顶部