介绍
在我们 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 用户。 请注意，它没有映射到“default”登录，而是被赋予了自己的条目。 再一次，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 更多的访问权限。
为了验证我们的来宾，让我们看一下第五列，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_t 域中运行进程。
我们建议您现在花时间与您从不同终端窗口创建的四个用户启动四个新的 SSH 会话。 这将帮助我们在需要时在不同帐户之间切换。
- 普通用户
- 切换用户
- 来宾用户
- 受限用户
接下来，我们切换到以普通用户身份登录的终端会话。 如果你还记得，我们在 第二篇教程 中创建了许多用户帐户，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 in Action 1：限制切换用户访问
要了解 SELinux 如何为用户帐户实施安全性，让我们考虑一下常规用户帐户。 作为系统管理员，您现在知道该用户拥有与 root 帐户相同的不受限制的 SELinux 权限 ，并且您想更改它。 具体来说，您不希望用户能够切换到其他帐户，包括 root 帐户。
让我们首先检查用户切换到另一个帐户的能力。 在以下代码片段中，常规用户切换到切换用户帐户。 我们假设他知道switcheduser的密码：
[regularuser@localhost ~]$ su - switcheduser Password: [switcheduser@localhost ~]$
接下来，我们返回以 root 用户身份登录的终端窗口，并更改常规用户的 SELinux 用户映射。 我们将常规用户映射到 user_u。
semanage login -a -s user_u regularuser
那么我们在这里做什么呢？ 我们将 (-a) 常规用户帐户添加到 SELinux (-s) 用户帐户 user_u。 在常规用户注销并重新登录之前，更改不会生效。
回到常规用户的终端窗口，我们首先从switcheduser切换回来：
[switcheduser@localhost ~]$ logout
接下来，常规用户也注销：
[regularuser@localhost ~]$ logout
然后我们打开一个新的终端窗口以普通用户身份连接。 接下来，我们尝试再次更改为switcheduser：
[regularuser@localhost ~]$ su - switcheduser
Password:
这是我们现在看到的：
su: Authentication failure
如果我们现在再次运行 id -Z 命令来查看常规用户的 SELinux 上下文，我们将看到输出与我们之前看到的完全不同：常规用户现在映射到 user_u。
[regularuser@localhost ~]$ id -Z
user_u:user_r:user_t:s0
那么你会在哪里使用这些限制呢？ 您可以考虑 IT 组织内的应用程序开发团队。 您的团队中可能有许多开发人员和测试人员为您的公司编写和测试最新的应用程序。 作为系统管理员，您知道开发人员正在从他们的帐户切换到一些高权限帐户，以便对您的服务器进行临时更改。 您可以通过限制他们切换帐户的能力来阻止这种情况发生。 （请注意，它仍然不会阻止他们直接以高权限用户身份登录）。
SELinux in Action 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 身份执行脚本时，它按预期工作：
[guestuser@localhost ~]$ ~/myscript.sh
This is a test script
接下来我们回到根终端窗口并将布尔设置 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 文件。 从根会话执行此操作：
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 正在阻止 /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 in Action 3：限制对服务的访问
在本系列的第一部分 an-introduction-to-selinux-on-centos-7-part-1-basic-concepts 中，我们在介绍用户、角色、域和类型的基本术语时讨论了 SELinux 角色。 现在让我们看看角色如何在限制用户访问方面发挥作用。 正如我们之前所说，SELinux 中的角色位于用户和进程域之间，并控制用户的进程可以进入哪些域。 当我们在文件安全上下文中看到角色时，角色并不那么重要。 对于文件，它以 object_r 的通用值列出。 在处理用户和流程时，角色变得很重要。
我们首先确保 httpd 守护进程没有在系统中运行。 作为 root 用户，您可以运行以下命令以确保进程已停止：
service httpd stop
接下来，我们切换到以受限用户身份登录的终端窗口，并尝试查看它的 SELinux 安全上下文。 如果您没有打开终端窗口，请针对系统启动一个新的终端会话，并以我们在本教程开始时创建的受限用户帐户登录。
[restricteduser@localhost ~]$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
因此，该帐户具有以 unconfined_u 用户身份运行并有权访问 unconfined_r 角色的默认行为。 但是，此帐户无权启动系统内的任何进程。 以下代码块显示受限制的用户正在尝试启动 httpd 守护程序并收到拒绝访问错误：
[restricteduser@localhost ~]$ service httpd start Redirecting to /bin/systemctl start httpd.service Failed to issue method call: Access denied
接下来，我们回到 root 用户终端窗口并确保已将受限用户帐户添加到 /etc/sudoers 文件中。 此操作将使受限用户帐户能够使用 root 权限。
visudo
然后在文件中，添加下面一行，保存退出：
restricteduser ALL=(ALL) ALL
如果我们现在退出受限用户终端窗口并重新登录，我们可以使用 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 用户的终端窗口并将受限用户映射到 SELinux user_r 帐户。 这是我们在另一个示例中为常规用户帐户所做的。
semanage login -a -s user_u restricteduser
回到受限制用户的终端窗口，我们注销并以受限制用户的身份在新的终端会话中重新登录。
现在，restricteduser 已被限制为 user_u（这意味着角色 user_r 和域 user_t），我们可以使用根用户窗口中的 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
以这个例子为例，如果受限制的用户帐户尝试启动 httpd 守护程序，则应拒绝访问，因为 httpd 进程在 httpd_t 域中运行，并且该域不是 user_r 角色有权访问的域之一。 我们知道 user_u（映射到受限用户）可以承担 user_r 角色。 即使已授予受限制的用户帐户 sudo 权限，这也会失败。
回到受限制用户帐户的终端窗口，我们现在尝试启动 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 代表 Access Vector Cache。 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 值一起使用。
在下面的代码片段中我们再次通过 grep 的 /var/log/message 文件查找 SELinux 相关的错误：
cat /var/log/messages | grep "SELinux is preventing"
在我们的系统中，我们查看最后一个错误。 这是当我们的受限用户尝试运行 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 的系统使用 MLS 作为其策略类型（在 /etc/selinux/config 文件中配置）时，它可以将某些文件和进程标记为特定级别的敏感度。 最低级别称为“电流灵敏度”，最高级别称为“间隙灵敏度”。
与敏感性密切相关的是资源的 类别 ，由 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 帐户的新用户或将正确的上下文应用于非标准文件位置。 了解如何破译错误日志。 检查各种守护进程的端口：如果使用非标准端口，请确保将它们正确分配给策略。
这一切都将与时间和实践结合在一起。 :)
