简介

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

注意事项 本教程中展示的命令、包和文件在CentOS 7上进行了测试。其他发行版的概念与此相同。

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

SELinux用户

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

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

当SELinux被强制执行时，每个常规Linux用户帐户都被映射到一个SELinux用户帐户。可以有多个用户帐户映射到同一个SELinux用户。这种映射使常规帐户能够继承其SELinux对应帐户的权限。

要查看此映射，我们可以运行Semanage登录-l命令：

1semanage login -l

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

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

此表中的第一列)类。现在，我们先忽略这一部分，然后再忽略这一列(服务)。

接下来，我们有根用户。请注意，它没有映射到** 默认** 登录，而是被赋予了自己的条目。同样，根用户也被映射到unconfined_u SELinux用户。

system_u是另一类用户，用于运行进程或守护进程。

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

1semanage user -l

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

 1Labeling MLS/       MLS/
 2SELinux User Prefix MCS Level MCS Range SELinux Roles
 3
 4guest_u user s0 s0 guest_r
 5root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
 6staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
 7sysadm_u user s0 s0-s0:c0.c1023 sysadm_r
 8system_u user s0 s0-s0:c0.c1023 system_r unconfined_r
 9unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r
10user_u user s0 s0 user_r
11xguest_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角色。这些角色中的每个角色都将拥有不同的域授权。

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

因此，这实际上意味着映射到unconfined_u用户的任何Linux用户都将有权运行unconfined_t域中运行的任何应用程序。

为了进行演示，我们以根用户身份运行id-z命令：

1id -Z

这显示了根目录 的SELinux安全上下文：

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

因此，根帐户被映射到unconfined_u SELinux用户，unconfined_u被授权给unconfined_r角色，而unconfined_r角色又被授权在unconfined_t域中运行进程。

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

规则用户
切换用户
来宾用户
受限用户

接下来，我们切换到以普通用户身份登录的终端会话。如果您还记得，我们在Second tutorial，]中创建了许多用户帐户，RegularUser就是其中之一。如果您尚未这样做，请打开一个单独的终端窗口，以常规用户身份连接到您的CentOS 7系统。如果我们从那里执行相同的id-z命令，输出将如下所示：

1[regularuser@localhost ~]$ id -Z

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

在这种情况下，RegaUser帐户被映射到unconfined_u SELinux用户帐户，并且它可以承担unconfined_r角色。该角色可以在不受限制的域中运行进程。这与根帐户也映射到的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行动一：限制切换用户访问

要了解SELinux如何加强用户帐户的安全性，让我们来考虑一下规则用户帐户。作为系统管理员，您现在知道该用户具有与根帐户相同的UNRESTRICTED_SELinux权限，并且您想要更改该权限。具体地说，您不希望用户能够切换到其他帐户，包括根帐户。

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

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

接下来，我们返回以根用户身份登录的终端窗口，并更改RegularUser的SELinux用户映射。我们将把RegarUser映射到User_u。

1semanage login -a -s user_u regularuser

那我们在这里做什么？我们正在将(-a)规则用户帐户添加到SELinux(-S)用户帐户user_u。更改要在规则用户注销并重新登录后才会生效。

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

1[switcheduser@localhost ~]$ logout

接下来，普通用户也会注销：

1[regularuser@localhost ~]$ logout

然后，我们打开一个新的终端窗口，以普通用户身份进行连接。接下来，我们尝试再次更改为SwitchedUser：

1[regularuser@localhost ~]$ su - switcheduser

1Password:

这就是我们现在看到的：

1su: Authentication failure

如果我们现在再次运行id-z命令来查看rularuser的SELinux上下文，我们将看到与之前看到的非常不同的输出：Regaruser现在被映射到user_u。

1[regularuser@localhost ~]$ id -Z

1user_u:user_r:user_t:s0

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

SELinux动作二：限制Linux运行Linux

让我们看另一个通过SELinux限制用户访问的例子。从 root 会话运行这些命令。

默认情况下，SELinux允许映射到Guest_t帐户的用户从其主目录执行脚本。我们可以运行getsebool命令检查布尔值：

1getsebool allow_guest_exec_content

输出显示该标志处于打开状态。

1guest_exec_content --> on

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

1semanage login -a -s guest_u guestuser

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

1semanage login -l

正如我们所看到的，GuestUser现在被映射到Guest_u SELinux用户帐户。

1Login Name SELinux User MLS/MCS Range Service
2
3__default__ unconfined_u s0-s0:c0.c1023       *
4guestuser guest_u s0                   *
5regularuser user_u s0                   *
6root unconfined_u s0-s0:c0.c1023       *
7system_u system_u s0-s0:c0.c1023       *

如果我们以GuestUser身份打开了一个终端窗口，我们将从该终端窗口注销，然后以GuestUser身份重新登录到一个新的终端窗口。

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

确认您在guestuser主目录中：

1[guestuser@localhost ~]$ pwd

1/home/guestuser

创建脚本：

1[guestuser@localhost ~]$ vi myscript.sh

脚本内容：

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

使脚本可执行：

1chmod u+x myscript.sh

当我们尝试以GuestUser身份执行该脚本时，它会按预期工作：

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

1This is a test script

接下来，我们返回根终端窗口，将布尔设置ALLOW_GUEST_EXEC_CONTENT更改为off并进行验证：

1setsebool allow_guest_exec_content off
2getsebool allow_guest_exec_content

1guest\_exec\_content --> off

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

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

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

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

我们将很快讨论SELinux错误消息，但现在，如果我们急于查看这种拒绝是在哪里记录的，我们可以查看/var/log/Messages文件。从根会话执行以下命令：

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

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

1Aug 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
2Aug 23 12:59:42 localhost python: SELinux is preventing /usr/bin/bash from execute access on the file .

该消息还显示了一个长ID值，并建议我们使用此ID运行selart命令以了解更多信息。以下命令显示(使用您自己的警报ID)：

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

实际上，输出向我们显示了有关错误的更多详细信息：

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

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

SELinux正在阻止/usr/bin/bash对该文件进行执行访问。

这让我们很好地了解了错误来自哪里。

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

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

SELinux在行动3：限制访问服务

在本series](https://andsky.com/tech/tutorials/an-introduction-to-selinux-on-centos-7-part-1-basic-concepts)的第一部分中，我们在介绍用户、角色、域和类型的基本术语时谈到了SELinux角色。现在，让我们看看角色如何在限制用户访问方面发挥作用。如前所述，SELinux中的一个角色位于用户和进程域之间，并控制用户的进程可以进入哪些域。当我们在文件安全上下文中看到角色时，它们并不那么重要。对于文件，它以泛型值Object_r列出。在处理用户和进程时，角色变得很重要。

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

1service httpd stop

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

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

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

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

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

1visudo

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

1restricteduser ALL=(ALL)      ALL

如果我们现在从受限用户终端窗口注销并重新登录，我们可以使用sudo权限启动和停止HTTPD服务：

1[restricteduser@localhost ~]$ sudo service httpd start

1We trust you have received the usual lecture from the local System
2Administrator. It usually boils down to these three things:
3
4    #1) Respect the privacy of others.
5    #2) Think before you type.
6    #3) With great power comes great responsibility.
7
8[sudo] password for restricteduser:
9Redirecting to /bin/systemctl start httpd.service

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

1[restricteduser@localhost ~]$ sudo service httpd stop

1Redirecting to /bin/systemctl stop httpd.service

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

要了解如何实现这一点，让我们切换回root用户的终端窗口，并将restricteduser映射到SELinux user_r帐户。这是我们在另一个例子中为regularuser帐户所做的。

1semanage login -a -s user_u restricteduser

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

既然refinteduser已经被限制为user_u(这意味着角色user_r和域user_t)，我们可以在根用户的窗口中使用seinfo命令验证其访问权限：

1seinfo -uuser_u -x

输出显示了user_u可以承担的角色。它们是对象_r和用户_r：

1user_u
2      default level: s0
3      range: s0
4      roles:
5         object_r
6         user_r

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

1seinfo -ruser_r -x

User_r有多个域有权进入：

 1user_r
 2      Dominated Roles:
 3         user_r
 4      Types:
 5         git_session_t
 6         sandbox_x_client_t
 7         git_user_content_t
 8         virt_content_t
 9         policykit_grant_t
10         httpd_user_htaccess_t
11         telepathy_mission_control_home_t
12         qmail_inject_t
13         gnome_home_t
14    	 ...
15    	 ...

但是，此列表是否将HTTPD_t显示为域之一？让我们使用筛选器尝试相同的命令：

1seinfo -ruser_r -x | grep httpd

该角色有权访问多个与HTTPD相关的域，但HTTPD_t不在其中：

1httpd_user_htaccess_t
2         httpd_user_script_exec_t
3         httpd_user_ra_content_t
4         httpd_user_rw_content_t
5         httpd_user_script_t
6         httpd_user_content_t

然后以本例为例，如果refinteduser帐户试图启动HTTPD守护进程，则访问应该被拒绝，因为HTTPD进程在HTTPD_t域中运行，而该域不是USER角色有权访问的域之一。我们知道user_u(映射到受限用户)可以承担user_r角色。即使受限用户帐户已被授予sudo权限，此操作也会失败。

返回到受限用户帐户的终端窗口，我们现在尝试启动HTTPD守护进程(我们以前能够停止它，因为该帐户被授予了sudo特权)：

1[restricteduser@localhost ~]$ sudo service httpd start

访问被拒绝：

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

因此，还有另一个例子说明了SELinux如何像一个看门人一样工作。

SELinux审核日志♪

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

/var/log/audit.log
/var/log/Messages

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

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

SELinux错误信息解密

我们在前面的一节中看到了一条SELinux错误消息(请参阅)。然后，我们使用grep命令筛选/var/log/Messages文件。幸运的是，SELinux附带了一些工具，可以让生活变得更容易一些。这些工具不是默认安装的，需要安装一些包，您应该已经在本教程的第一部分中安装了这些包。

第一个命令是osearch。如果auditd守护进程正在运行，则可以使用此命令。在下面的代码片段中，我们尝试查看与HTTPD守护进程相关的所有错误消息。确保您使用的是您的超级用户帐户：

1ausearch -m avc -c httpd

在我们的系统中列出了许多条目，但我们将集中讨论最后一个条目：

1----
2time->Thu Aug 21 16:42:17 2014
3...
4type=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事件。
拒绝{getattr}：尝试的权限和获得的结果。在这种情况下，获取属性操作被拒绝。
PID=10204。这是尝试访问的进程的进程ID。
comm：进程id本身意义不大。COMM属性显示进程命令。在本例中，它是HTTPD。我们立即知道错误来自Web服务器。
路径：被访问的资源的位置。在本例中，它是/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相关错误：

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

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

1...
2Aug 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值运行seert t，并能够看到详细信息(您的ID值对于您的系统来说应该是唯一的)：

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

 1SELinux is preventing /usr/bin/su from using the setuid capability.
 2
 3...
 4
 5Raw Audit Messages
 6type=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
 7
 8type=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)
 9
10Hash: su,user_t,user_t,capability,setuid

我们已经看到了seert‘输出的前几行是如何告诉我们补救步骤的。但是，如果我们现在查看输出流的末尾附近，我们可以看到原始审计消息部分。这里的条目来自我们前面讨论过的audit.log`文件，因此您可以使用该部分来帮助您解释这里的输出。

多级安全

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

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

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

1ls -Z /etc/vsftpd/vsftpd.conf

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

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

敏感性是_hierarchical_ multilevel安全机制的一部分。通过层次结构，我们的意思是敏感性级别可以越来越深，以获得文件系统中更安全的内容。级别0（用s0表示)是最低的敏感度级别，相当于公共。`可能存在具有更高s值的其他敏感度级别：例如，内部、机密或监管级别可以分别由s1、s2和s3表示。此映射不是由策略规定的：系统管理员可以配置每个敏感性级别的含义。

当启用SELinux的系统使用MLS作为其策略类型(在/etc/selinux/config文件中配置)时，它可以将某些文件和进程标记为具有一定级别的敏感度。最低电平称为电流敏感度，最高电平称为间隙敏感度。

类别的示例可以是部门名称、客户名称、项目等。分类的目的是进一步微调访问控制。例如，您可以为来自两个不同内部部门的用户标记具有机密敏感性的某些文件。

对于SELinux安全上下文，当实现类别时，敏感度和类别一起工作。使用一系列敏感度级别时，格式为显示敏感度级别，用连字符分隔(例如，S0-S2)。使用类别时，显示的范围中间有一个圆点。敏感度和类别值用冒号(：)分隔。

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

1user_u:object_r:etc_t:s0:c0.c2

这里只有一个敏感度，那就是S0。类别级别也可以写为c0-c2。

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

1cat /etc/selinux/targeted/setrans.conf

 1#
 2# Multi-Category Security translation table for SELinux
 3#
 4#
 5# Objects can be categorized with 0-1023 categories defined by the admin.
 6# Objects can be in more than one category at a time.
 7# Categories are stored in the system as c0-c1023. Users can use this
 8# table to translate the categories into a more meaningful output.
 9# Examples:
10# s0:c0=CompanyConfidential
11# s0:c1=PatientRecord
12# s0:c2=Unclassified
13# s0:c3=TopSecret
14# s0:c1,c3=CompanyConfidentialRedHat
15s0=SystemLow
16s0-s0:c0.c1023=SystemLow-SystemHigh
17s0:c0.c1023=SystemHigh

我们不会在这里深入讨论敏感性和类别的细节。只需知道，只有当进程的敏感度和类别级别高于资源的敏感度和类别级别时，才允许进程对资源进行读访问(即，进程的域_支配_资源类型)。当该资源的敏感度/类别级别低于该资源的敏感度/类别级别时，该进程可以写入该资源。

结论

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

整本书都是关于SELinux主题的，您可能会花几个小时试图弄清楚不同的包、配置文件、命令及其对安全性的影响。那么，你接下来要去哪里呢？

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

这一切都会随着时间和实践而来。：)

CentOS 7 上的 SELinux 简介 - 第 3 部分：用户

简介