简介

在我们 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 用户映射。我们将普通用户映射到用户_u。

semanage login -a -s user_u regularuser

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

回到普通用户终端窗口,我们首先从切换用户切换回来:

[switcheduser@localhost ~]$ logout

接下来,常规用户也注销:

[regularuser@localhost ~]$ logout

然后我们打开一个新的终端窗口以普通用户身份连接。接下来,我们尝试再次更改为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 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:限制对服务的访问

在本系列的第部分中,我们在介绍用户、角色、域和类型的基本术语时谈到了 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 用户_r 帐户。这是我们在另一个示例中为常规用户帐户所做的。

semanage login -a -s user_u restricteduser

回到限制用户终端窗口,我们注销并以受限用户身份在新的终端会话中重新登录。

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

seinfo -uuser_u -x

输出显示 user_u 可以承担的角色。它们是对象_r 和用户_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 角色有权访问的域之一。我们知道用户_u(映射到受限用户)可以承担用户_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

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

• typeu003dAVC and avc:AVC代表_Access Vector Cache_。 SELinux 缓存资源和进程的访问控制决策。此缓存称为访问向量缓存 (AVC)。这就是为什么 SELinux 访问拒绝消息也称为“AVC 拒绝”的原因。这两个信息字段表示该条目来自 AVC 日志并且它是一个 AVC 事件。

• denied { getattr }:尝试的权限和得到的结果。在这种情况下,获取属性操作被拒绝。

• PIDu003d10204。这是尝试访问的进程的进程 ID。

• comm:进程id本身没有多大意义。 comm 属性显示进程命令。在这种情况下,它是 httpd。我们立即知道错误来自 Web 服务器。

• path:被访问的资源的位置。在这种情况下,它是 /www/html/index.html 下的一个文件。

• dev and ino:目标资源所在的设备及其inode地址。

• scontext:进程的安全上下文。我们可以看到源码在 httpd_t 域下运行。

• tcontext:目标资源的安全上下文。在这种情况下,文件类型为默认_t。

• tclass:目标资源的类。在这种情况下,它是一个文件。

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

我们已经看到了sealert工具。此命令可与记录在/var/log/messages文件中的错误消息的 id 值一起使用。

在下面的代码片段中我们再次通过/var/log/message文件查找 SELinux 相关错误的grep:

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

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

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

与敏感性密切相关的是资源的_category_,由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 帐户的新用户或将正确的上下文应用于非标准文件位置。了解如何破译错误日志。检查各种守护进程的端口:如果使用非标准端口,请确保将它们正确分配给策略。

这一切都将与时间和实践结合在一起。 :)