介绍

在我们 SELinux 教程的最后一部分中，我们将讨论 SELinux 用户以及如何微调他们的访问权限。我们还将了解 SELinux 错误日志以及如何理解错误消息。

注意 本教程中显示的命令、包和文件在 CentOS 7 上进行了测试。其他发行版的概念保持不变。

在本教程中，除非另有说明，否则我们将以 root 用户身份运行命令。如果您无权访问 root 帐户并使用具有 sudo 权限的另一个帐户，则需要在命令之前使用sudo关键字。

SELinux 用户

SELinux 用户是不同于普通 Linux 用户帐户的实体，包括 root 帐户。SELinux 用户不是您使用特殊命令创建的，也没有自己的服务器登录访问权限。相反，SELinux 用户是在启动时加载到内存中的策略中定义的，并且这些用户中只有少数几个。用户名以_u结尾，就像类型或域名以_t结尾，角色以_r结尾一样。不同的 SELinux 用户在系统中拥有不同的权限，这就是它们的用处。

文件安全上下文第一部分中列出的 SELinux 用户是拥有该文件的用户。这就像您从常规ls -l命令输出中看到文件的所有者一样。进程上下文中的用户标签显示正在运行进程的 SELinux 用户的权限。

强制执行 SELinux 时，每个常规 Linux 用户帐户都会映射到一个 SELinux 用户帐户。可以有多个用户帐户映射到同一个 SELinux 用户。此映射使常规帐户能够继承其 SELinux 对应项的权限。 要查看此映射，我们可以运行以下semanage login -l命令：

semanage login -l

在 CentOS 7 中，我们可能会看到：

Login Name           SELinux User         MLS/MCS Range        Service
__default__          unconfined_u         s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *

此表中的第一列“登录名”代表本地 Linux 用户帐户。但是这里只列出了三个，您可能会问，我们在本教程的第二部分中不是创建了几个帐户吗？是的，它们由显示为default的条目表示。任何常规 Linux 用户帐户都会首先映射到**默认(default)**登录名。接下来将其映射到名为 unconfined_u 的 SELinux 用户。在我们的例子中，这是第一行的第二列。第三列显示用户的多级安全/多类别安全 (MLS/MCS) 类。现在，让我们忽略该部分以及之后的列（服务）。

接下来，我们有root用户。请注意，它并未映射到“默认”登录名，而是已为其提供了自己的条目。同样，root 也映射到 unconfined_u SELinux 用户。

system_u 是不同类别的用户，用于运行进程或守护进程。

要查看系统中有哪些 SELinux 用户可用，我们可以运行以下semanage user命令：

semanage user -l

CentOS 7 系统中的输出应如下所示：

                 Labeling   MLS/       MLS/

SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles
guest_u         user       s0         s0                             guest_r
root            user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
staff_u         user       s0         s0-s0:c0.c1023                 staff_r sysadm_r system_r unconfined_r
sysadm_u        user       s0         s0-s0:c0.c1023                 sysadm_r
system_u        user       s0         s0-s0:c0.c1023                 system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023                 system_r unconfined_r
user_u          user       s0         s0                             user_r
xguest_u        user       s0         s0                             xguest_r

这张更大的表格是什么意思？首先，它显示了策略定义的不同 SELinux 用户。我们以前见过像 unconfined_u 和 system_u 这样的用户，但现在我们看到了其他类型的用户，如 guest_u、staff_u、sysadm_u、user_u 等。这些名称在某种程度上表明了与它们相关的权利。例如，我们或许可以假设 sysadm_u 用户比 guest_u 拥有更多的访问权限。

为了验证我们的猜测(原文中为guest，可能是拼写错误)，让我们看看第五列，SELinux 角色。如果您还记得本教程的第一部分，SELinux 角色就像用户和进程之间的网关。我们还将它们与过滤器进行了比较：用户可以进入一个角色，只要将该角色授予它。如果角色被授权访问某个进程域，则与该角色关联的用户就能够进入该进程域。

现在从这个表中我们可以看到unconfined_u用户被映射到system_r和unconfined_r角色。虽然这里不明显，但 SELinux 策略实际上允许这些角色在unconfined_t域中运行进程。同样，用户sysadm_u被授予 sysadm_r 角色，但 guest_u 映射到 guest_r 角色。这些角色中的每一个都有不同的域授权给他们。

现在，如果我们退后一步，我们还从第一个代码片段中看到，**默认(default)**登录名映射到 unconfined_u 用户，就像 root 用户映射到 unconfined_u 用户一样。由于 default 登录名代表任何常规 Linux 用户帐户，因此这些帐户也将被授予 system_r 和 unconfined_r 角色。

所以这真正意味着映射到 unconfined_u 用户的任何 Linux 用户都将有权运行任何在 unconfined_t 域中运行的应用程序。

为了演示这一点，让我们以 root 用户身份运行id -Z命令：

id -Z

这显示了root的 SELinux 安全上下文：

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

所以root账户被映射到unconfined_u SELinux用户，unconfined_u被授权为unconfined_r角色，而unconfined_r角色又被授权运行unconfined_t域中的进程。

我们建议您现在花时间从不同的终端窗口中用您创建的四个用户开启四个新的 SSH 会话。这将帮助我们在需要时在不同帐户之间切换。

• regularuser
• switcheduser
• guestuser
• restricteduser

接下来，我们切换到以regularuser用户身份登录的终端会话。如果您还记得，我们在第二个教程中创建了许多用户帐户，regularuser 就是其中之一。如果您还没有这样做，请打开一个单独的终端窗口，以regularuser用户身份连接到您的 CentOS 7 系统。如果我们id -Z从那里执行相同的命令，输出将如下所示：

[regularuser@localhost ~]$ id -Z

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

在这种情况下，regulauser 帐户被映射到 unconfined_u SELinux 用户帐户，它可以承担 unconfined_r 角色。该角色可以在不受限制的域中运行进程。这与 root 帐户也映射到的 SELinux 用户/角色/域相同。这是因为 SELinux 目标策略允许登录用户在不受限制的域中运行。

之前我们已经看到了一些 SELinux 用户的列表：

• guest_u：此用户无权访问 X-Window 系统 (GUI) 或网络，也无法执行 su / sudo 命令。
• xguest_u：该用户可以访问 GUI 工具，并且可以通过 Firefox 浏览器访问网络。
• user_u：此用户拥有比来宾帐户（GUI 和网络）更多的访问权限，但无法通过运行 su 或 sudo 来切换用户。
• staff_u : 与 user_u 权限相同，只是可以执行 sudo 命令以获得 root 权限。
• system_u：此用户用于运行系统服务，而不是映射到常规用户帐户。

SELinux 实战 1：限制切换用户访问

要了解 SELinux 如何为用户帐户实施安全性，让我们考虑一下regulauser帐户。作为系统管理员，您现在知道用户拥有与root 帐户相同的不受限制的SELinux 权限，并且您想更改它。具体来说，您不希望用户能够切换到其他帐户，包括 root 帐户。

让我们首先检查用户切换到另一个帐户的能力。在以下代码片段中，regulauser切换到 switchuser帐户。我们假设他知道 switchuser 的密码：

[regularuser@localhost ~]$ su - switcheduser
Password:
[switcheduser@localhost ~]$

接下来，我们回到以root用户身份登录的终端窗口，并更改regulauser的 SELinux 用户映射。我们将把regularuser 映射到user_u。

semanage login -a -s user_u regularuser

那么我们在这里做了什么呢？我们将 regulauser帐户添加 (-a)到 SELinux (-s) 用户帐户 user_u。在普通用户注销并重新登录之前，更改不会生效。

回到regularuser的终端窗口，我们首先从switcheduser切换回来：

[switcheduser@localhost ~]$ logout

接下来，regularuser也注销：

[regularuser@localhost ~]$ logout

然后我们打开一个新的终端窗口以作为regularuser连接。接下来，我们尝试再次更改为switcheduser：

[regularuser@localhost ~]$ su - switcheduser

Password:

这是我们现在看到的：

su: Authentication failure

如果我们现在再次运行id -Z命令以查看regularuser的 SELinux 上下文，我们将看到输出与我们之前看到的有很大不同：regularuser现在映射到 user_u。

[regularuser@localhost ~]$ id -Z

user_u:user_r:user_t:s0

那么你会在哪里使用这样的限制呢？您可以想象一下 IT 组织内的应用程序开发团队。您的团队中可能有许多开发人员和测试人员，为您的公司编码和测试最新的应用程序。作为系统管理员，您知道开发人员正在从他们的帐户切换到一些高特权帐户，以对您的服务器进行临时更改。您可以通过限制他们切换帐户的能力来阻止这种情况的发生。（请注意，这仍然不会阻止他们以高特权用户的身份直接登录）。

SELinux 实战 2：限制运行脚本的权限

让我们看另一个通过 SELinux 限制用户访问的例子。从root会话运行这些命令。 默认情况下，SELinux 允许映射到 guest_t 帐户的用户从其主目录执行脚本。我们可以运行getsebool命令来检查布尔值：

getsebool allow_guest_exec_content

输出显示标志已打开。

guest_exec_content --> on

为了验证它的效果，让我们首先更改我们在本教程开头创建的 guestuser 帐户的 SELinux 用户映射。我们将以 root 用户身份执行此操作。

semanage login -a -s guest_u guestuser

我们可以通过再次运行semanage login -l命令来验证操作：

semanage login -l

正如我们所见，guestuser 现在映射到 guest_u SELinux 用户帐户。

Login Name           SELinux User         MLS/MCS Range        Service
__default__          unconfined_u         s0-s0:c0.c1023       *
guestuser            guest_u              s0                   *
regularuser          user_u               s0                   *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *

如果我们有一个以guestuser 身份打开的终端窗口，我们将从它注销并以guestuser 身份重新登录一个新的终端窗口。

接下来我们将在用户的主目录中创建一个非常简单的 bash 脚本。以下代码块首先检查主目录，然后创建文件并在控制台上读取它。最后执行权限被更改。

验证您是否位于guestuser主目录中：

[guestuser@localhost ~]$ pwd

/home/guestuser

创建脚本：

[guestuser@localhost ~]$ vi myscript.sh

脚本内容：

#!/bin/bash
echo "This is a test script"

使脚本可执行：

chmod u+x myscript.sh

当我们尝试以访客用户身份执行脚本时，它按预期工作：

[guestuser@localhost ~]$ ~/myscript.sh

This is a test script

接下来我们回到root终端窗口并将布尔值设置 allow_guest_exec_content 更改为off并验证它：

setsebool allow_guest_exec_content off
getsebool allow_guest_exec_content

guest\_exec\_content --> off

返回以guestuser 身份登录的控制台，我们尝试再次运行该脚本。这一次，访问被拒绝：

[guestuser@localhost ~]$ ~/myscript.sh

-bash: /home/guestuser/myscript.sh: Permission denied

所以这就是 SELinux 如何在 DAC 之上应用额外的安全层。即使用户对在他们自己的主目录中创建的脚本具有完全的读、写、执行权限，他们仍然可以阻止执行它。你会在哪里需要它？好吧，想想一个生产系统。您知道开发人员可以访问它，就像为您公司工作的一些承包商一样。您希望他们访问服务器以查看错误消息和日志文件，但您不希望他们执行任何 shell 脚本。为此，您可以先启用 SELinux，然后确保设置了相应的布尔值。

我们将很快讨论 SELinux 错误消息，但现在，如果我们急于查看此拒绝记录的位置，我们可以查看该/var/log/messages文件。从root会话执行此操作：

grep "SELinux is preventing" /var/log/messages

CentOS 7 服务器中文件中的最后两条消息显示访问拒绝：

Aug 23 12:59:42 localhost setroubleshoot: SELinux is preventing /usr/bin/bash from execute access on the file . For complete SELinux messages. run sealert -l 8343a9d2-ca9d-49db-9281-3bb03a76b71a
Aug 23 12:59:42 localhost python: SELinux is preventing /usr/bin/bash from execute access on the file .

该消息还显示了一个长 ID 值，并建议我们使用此 ID运行sealert命令以获取更多信息。以下命令显示了这一点（使用您自己的警报 ID）：

sealert -l 8343a9d2-ca9d-49db-9281-3bb03a76b71a

事实上，输出向我们展示了关于错误的更多细节：

SELinux is preventing /usr/bin/bash from execute access on the file .
*****  Plugin catchall_boolean (89.3 confidence) suggests   ******************
If you want to allow guest to exec content
Then you must tell SELinux about this by enabling the 'guest\_exec\_content' boolean.
You can read 'None' man page for more details.
Do
setsebool -P guest\_exec\_content 1
*****  Plugin catchall (11.6 confidence) suggests   **************************
...

这是大量输出，但请注意开头的几行：

SELinux is preventing /usr/bin/bash from execute access on the file . SELinux 阻止 /usr/bin/bash 对文件的执行权限。

这让我们很清楚错误的来源。

接下来的几行还告诉您如何修复错误：

If you want to allow guest to exec content
Then you must tell SELinux about this by enabling the 'guest\_exec\_content' boolean.
...
setsebool -P guest\_exec\_content 1

SELinux 实战 3：限制对服务的访问

在本系列的第一部分中，我们在介绍用户、角色、域和类型的基本术语时谈到了 SELinux 角色。现在让我们看看角色如何在限制用户访问方面发挥作用。正如我们之前所说，SELinux 中的角色位于用户和进程域之间，并控制用户进程可以进入的域。当我们在文件安全上下文中看到角色时，角色并不那么重要。对于文件，它与 object_r 的通用值一起列出。在处理用户和进程时，角色变得很重要。

让我们首先确保系统中没有运行 httpd 守护进程。作为 root 用户，您可以运行以下命令以确保该进程已停止：

service httpd stop

接下来，我们切换到以restricteduser身份登录的终端窗口，并尝试查看它的 SELinux 安全上下文。如果您没有打开终端窗口，请针对系统启动一个新的终端会话，并以我们在本教程开头创建的restricteduser帐户登录。

[restricteduser@localhost ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

因此，该帐户具有作为 unconfined_u 用户运行并有权访问 unconfined_r 角色的默认行为。但是，该帐户无权启动系统内的任何进程。以下代码块显示restricteduser正在尝试启动 httpd 守护程序并收到访问被拒绝的错误：

[restricteduser@localhost ~]$ service httpd start
Redirecting to /bin/systemctl start  httpd.service
Failed to issue method call: Access denied

接下来，我们回到 root 用户终端窗口，并确保已将restricteduser帐户添加到 /etc/sudoers 文件中。此操作将使restricteduser帐户能够使用 root 权限。

visudo

然后在文件中，添加以下行，保存并退出：

restricteduser ALL=(ALL)      ALL

如果我们现在退出restricteduser终端窗口并重新登录，我们可以使用 sudo 权限启动和停止 httpd 服务：

[restricteduser@localhost ~]$ sudo service httpd start

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for restricteduser:
Redirecting to /bin/systemctl start  httpd.service

用户现在也可以停止服务：

[restricteduser@localhost ~]$ sudo service httpd stop

Redirecting to /bin/systemctl stop  httpd.service

这很正常：系统管理员授予他们信任的用户帐户的 sudo 访问权限。但是，如果您想阻止该特定用户启动 httpd 服务，即使该用户的帐户已在 sudoers 文件中列出，该怎么办？

要了解如何实现这一点，让我们切换回 root 用户的终端窗口并将restricteduser映射到 SELinux user_u (原文中为user_r，应为拼写错误)帐户。就像我们在另一个示例中为regularuser帐户所做的。

semanage login -a -s user_u restricteduser

返回到restricteduser的终端窗口，我们注销并以restricteduser的身份在新的终端会话中重新登录。

现在，restricteduser 已被限制为 user_u（这意味着角色 user_r 和域 user_t），我们可以使用root用户窗口中的seinfo命令验证其访问权限：

seinfo -uuser_u -x

输出显示了 user_u 可以承担的角色。它们是 object_r 和 user_r：

   user_u
      default level: s0
      range: s0
      roles:
         object_r
         user_r

更进一步，我们可以运行seinfo命令来检查 user_r 角色有权进入哪些域：

seinfo -ruser_r -x

user_r 被授权进入许多域：

   user_r
      Dominated Roles:
         user_r
      Types:
         git_session_t
         sandbox_x_client_t
         git_user_content_t
         virt_content_t
         policykit_grant_t
         httpd_user_htaccess_t
         telepathy_mission_control_home_t
         qmail_inject_t
         gnome_home_t
         ...
         ...

但是此列表显示的域中是否包含 httpd_t ？让我们试试对同样的命令进行过滤：

seinfo -ruser_r -x | grep httpd

该角色可以访问许多与 httpd 相关的域，但 httpd_t 不是其中之一：

         httpd_user_htaccess_t
         httpd_user_script_exec_t
         httpd_user_ra_content_t
         httpd_user_rw_content_t
         httpd_user_script_t
         httpd_user_content_t

以这个例子为例，如果restricteduser帐户尝试启动 httpd 守护程序，则应该拒绝访问，因为 httpd 进程在 httpd_t 域中运行，而该域不是 user_r 角色有权访问的域之一。我们知道 user_u（映射到restricteduser）会承担 user_r 角色。即使受限制的用户帐户已被授予 sudo 权限，该操作也会失败。

回到restricteduser帐户的终端窗口，我们现在尝试启动 httpd 守护进程（我们之前能够停止它，因为该帐户被授予了 sudo 权限）：

[restricteduser@localhost ~]$ sudo service httpd start

访问被拒绝：

sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted

所以还有另一个例子说明 SELinux 如何像看门人一样工作。

SELinux 审计日志

作为系统管理员，您可能有兴趣查看 SELinux 记录的错误消息。这些消息记录在特定文件中，它们可以提供有关拒绝访问的详细信息。在 CentOS 7 系统中，您可以查看两个文件：

• /var/log/audit/audit.log
• /var/log/messages

这些文件分别由 auditd 守护程序和 rsyslogd 守护程序填充。那么这些守护进程有什么作用呢？手册页说 auditd 守护进程是 Linux 审计系统的用户空间组件，而 rsyslogd 是提供消息记录支持的系统实用程序。简而言之，这些守护进程将错误消息记录在这两个文件中。

如果 auditd 守护程序正在运行，将使用/var/log/audit/audit.log文件。如果 auditd 已停止且 rsyslogd 正在运行，则使用/var/log/messages文件。如果两个守护进程都在运行，则同时使用两个文件：/var/log/audit/audit.log记录详细信息，而易于阅读的版本保存在/var/log/messages。

解密 SELinux 错误消息

我们查看了前面部分中的一条 SELinux 错误消息（请参阅“SELinux in Action 2: Restricting Permissions to Run Scripts”）。然后我们使用grep命令来筛选/var/log/messages文件。幸运的是，SELinux 附带了一些工具，让生活变得更轻松。这些工具默认不安装，需要安装一些包，您应该在本教程的第一部分中安装了这些包。 第一个命令是ausearch。如果 auditd 守护程序正在运行，我们可以使用此命令。在下面的代码片段中，我们试图查看与 httpd 守护程序相关的所有错误消息。确保您在root帐户中：

ausearch -m avc -c httpd

在我们的系统中列出了许多条目，但我们将专注于最后一个：

----
time->Thu Aug 21 16:42:17 2014
...
type=AVC msg=audit(1408603337.115:914): avc:  denied  { getattr } for  pid=10204 comm="httpd" path="/www/html/index.html" dev="dm-0" ino=8445484 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

即使是有经验的系统管理员也会对此类消息感到困惑，除非他们知道自己在寻找什么。为了理解它，让我们拆开每个字段：

• type=AVC 和 avc：AVC 代表访问向量缓存。SELinux 缓存资源和进程的访问控制决策。此缓存称为访问向量缓存 (AVC)。这就是为什么 SELinux 访问拒绝消息也被称为“AVC 拒绝”的原因。这两个信息字段表示该条目来自 AVC 日志并且它是一个 AVC 事件。
• denied { getattr }：尝试的权限及其获得的结果。在这种情况下，获取属性操作被拒绝。
• pid=10204。这是尝试访问的进程的进程 ID。
• comm：进程 ID 本身没有多大意义。comm 属性显示进程命令。在本例中，它是 httpd。我们立即知道错误来自 Web 服务器。
• path：被访问的资源的位置。在本例中，它是/www/html/index.html 下的一个文件。
• dev和ino：目标资源所在的设备及其inode地址。
• scontext：进程的安全上下文。我们可以看到源（进程）运行在 httpd_t 域下。
• tcontext：目标资源的安全上下文。在本例中，文件类型是 default_t。
• tclass：目标资源的类。在本例中，它是一个文件。

如果仔细观察，进程域是 httpd_t，文件的类型上下文是 default_t。由于 httpd 守护进程在受限域中运行，并且 SELinux 策略规定该域无权访问 default_t 类型的文件，因此访问被拒绝。

我们已经看到了这个sealert工具。此命令可以与记录在/var/log/messages文件中的错误消息的 id 值一起使用。 在以下代码片段中，我们再次通过对/var/log/message文件执行grep查找 SELinux 相关错误：

cat /var/log/messages | grep "SELinux is preventing"

在我们的系统中，我们查看最后一个错误。这是当我们的restricteduser尝试运行 httpd 守护程序时记录的错误：

...
Aug 25 11:59:46 localhost setroubleshoot: SELinux is preventing /usr/bin/su from using the setuid capability. For complete SELinux messages. run sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbce

按照建议，我们使用 ID 值运行sealert并能够查看详细信息（您的 ID 值应该是您系统的唯一值）：

sealert -l e9e6c6d8-f217-414c-a14e-4bccb70cfbce

SELinux is preventing /usr/bin/su from using the setuid capability.

...

Raw Audit Messages
type=AVC msg=audit(1408931985.387:850): avc:  denied  { setuid } for  pid=5855 comm="sudo" capability=7  scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=capability

type=SYSCALL msg=audit(1408931985.387:850): arch=x86_64 syscall=setresuid success=no exit=EPERM a0=ffffffff a1=1 a2=ffffffff a3=7fae591b92e0 items=0 ppid=5739 pid=5855 auid=1008 uid=0 gid=1008 euid=0 suid=0 fsuid=0 egid=0 sgid=1008 fsgid=0 tty=pts2 ses=22 comm=sudo exe=/usr/bin/sudo subj=user_u:user_r:user_t:s0 key=(null)

Hash: su,user_t,user_t,capability,setuid

我们已经看到sealert输出的前几行如何告诉我们修复步骤。但是，如果我们现在查看输出流的末尾，我们可以看到“原始审计消息”部分。此处的条目来自我们之前讨论过的audit.log文件，因此您可以使用该部分来帮助您解释此处的输出。

多级安全

多级安全或MLS是 SELinux 安全上下文的细粒度部分。

到目前为止，在我们关于进程、用户或资源的安全上下文的讨论中，我们已经讨论了三个属性：SELinux 用户、SELinux 角色和 SELinux 类型或域。安全上下文的第四个字段显示敏感度和可选的资源类别。

为了理解它，让我们考虑 FTP 守护进程的配置文件的安全上下文：

ls -Z /etc/vsftpd/vsftpd.conf

安全上下文的第四个字段显示敏感度为 s0。

-rw-------. root root system_u:object_r:etc_t:s0       /etc/vsftpd/vsftpd.conf

敏感性是分层多级安全机制的一部分。通过层次结构，我们对于文件系统中更安全的内容的敏感度级别的表示可以越来越深入。级别 0（由 s0 表示）是最低的敏感级别，相当于“公开”。可以有其他具有更高 s 值的敏感度级别：例如，内部、机密或监管可以分别用 s1、s2 和 s3 来描述。策略没有规定这种映射：系统管理员可以配置每个敏感级别的含义。

当启用 SELinux 的系统对其策略类型（在/etc/selinux/config文件中配置）使用 MLS 时，它可以以特定级别的敏感度标记特定文件和进程。最低级别称为“current敏感度”，最高级别称为“clearance（许可）敏感度”。

与敏感性并驾齐驱的是资源的类别，用 c 表示。类别可以被视为分配给资源的标签。类别的示例可以是部门名称、客户名称、项目等。分类的目的是进一步微调访问控制。例如，您可以为来自两个不同内部部门的用户标记具有机密敏感性的某些文件。

对于 SELinux 安全上下文，在实现类别时，敏感性和类别会协同工作。使用一系列灵敏度级别时，格式是显示用连字符分隔的灵敏度级别（例如，s0-s2）。使用类别时，中间有一个点表示一个范围。敏感度和类别值由冒号 (:) 分隔。

这是敏感度/类别对的示例：

user_u:object_r:etc_t:s0:c0.c2  

这里只有一个敏感度级别，即 s0。类别级别也可以写为 c0-c2。

那么你在哪里分配你的类别级别？让我们从/etc/selinux/targeted/setrans.conf文件中找到详细信息：

cat /etc/selinux/targeted/setrans.conf

#

# Multi-Category Security translation table for SELinux
#
#
# Objects can be categorized with 0-1023 categories defined by the admin.
# Objects can be in more than one category at a time.
# Categories are stored in the system as c0-c1023.  Users can use this
# table to translate the categories into a more meaningful output.
# Examples:
# s0:c0=CompanyConfidential
# s0:c1=PatientRecord
# s0:c2=Unclassified
# s0:c3=TopSecret
# s0:c1,c3=CompanyConfidentialRedHat
s0=SystemLow
s0-s0:c0.c1023=SystemLow-SystemHigh
s0:c0.c1023=SystemHigh

我们不会在这里详细介绍敏感性和类别。只要知道一个进程只有在其敏感度和类别级别高于资源的敏感度和类别级别时才允许对资源进行读访问（即进程域支配资源类型）。当其敏感度/类别级别低于资源的敏感度/类别级别时，进程可以写入资源。

总结

在这个由三部分组成的系列文章中，我们试图在很短的时间内涵盖有关 Linux 安全性的广泛主题。如果我们现在看看我们的系统，我们已经安装了一个简单的 Apache Web 服务器，它的内容是从自定义目录提供的。我们还有一个 FTP 守护进程在我们的服务器中运行。已创建一些用户的访问权限已被限制。在进行过程中，我们使用 SELinux 包、文件和命令来满足我们的安全需求。在此过程中，我们还学习了如何查看 SELinux 错误消息并理解它们。

整本书都是关于 SELinux 主题的，您可能会花费数小时试图找出不同的包、配置文件、命令及其对安全性的影响。那么你从这里去哪里呢？

我要做的一件事是提醒您不要在生产系统上测试任何东西。一旦您掌握了基础知识，就可以通过在您的生产机器的测试副本上启用它来开始使用 SELinux。确保审计守护进程正在运行并密切关注错误消息。检查任何阻止服务启动的拒绝。玩转布尔值设置。列出保护系统的可能步骤，例如创建映射到最低权限 SELinux 帐户的新用户或将正确的上下文应用到非标准文件位置。了解如何解读错误日志。检查各种守护进程的端口：如果使用非标准端口，请确保它们已正确分配给策略。

这一切都会随着时间和练习而结合在一起。:)