今年是我们一起庆祝 SELinux 纪念日的第十个年头了（LCTT 译者注：本文发表于 2013 年）。真是太难以置信了！SELinux 最初在 Fedora Core 3 中被引入，随后加入了红帽企业版 Linux 4。从来没有使用过 SELinux 的家伙，你可要好好儿找个理由了……

SElinux 是一个标签型系统。每一个进程都有一个标签。操作系统中的每一个文件/目录 客体 （ object ） 也都有一个标签。甚至连网络端口、设备，乃至潜在的主机名都被分配了标签。我们把控制访问进程的标签的规则写入一个类似文件的客体标签中，这些规则我们称之为 策略 （ policy ） 。内核强制实施了这些规则。有时候这种“强制”被称为 强制访问控制体系 （ Mandatory Access Control ） （MAC）。

一个客体的拥有者对客体的安全属性并没有自主权。标准 Linux 访问控制体系，拥有者/分组 + 权限标志如 rwx，常常被称作 自主访问控制 （ Discretionary Access Control ） （DAC）。SELinux 没有文件 UID 或拥有权的概念。一切都被标签控制，这意味着在没有至高无上的 root 权限进程时，也可以设置 SELinux 系统。

注意： SELinux 不允许你摒弃 DAC 控制。SELinux 是一个并行的强制模型。一个应用必须同时支持 SELinux 和 DAC 来完成特定的行为。这可能会导致管理员迷惑为什么进程被拒绝访问。管理员被拒绝访问是因为在 DAC 中有些问题，而不是在 SELinux 标签。

类型强制

让我们更深入的研究下标签。SELinux 最主要的“模型”或“强制”叫做 类型强制 （ type enforcement ） 。基本上这意味着我们根据进程的类型来定义其标签，以及根据文件系统客体的类型来定义其标签。

打个比方

想象一下在一个系统里定义客体的类型为猫和狗。猫（CAT）和狗（DOG）都是 进程类型 （ process type ） 。

我们有一类希望能与之交互的客体，我们称之为食物。而我希望能够为食物增加类型：cat_food （猫的食物）和 dog_food（狗的食物）。

作为一个策略制定者，我可以说一只狗有权限去吃狗粮（dog_chow），而一只猫有权限去吃猫粮（cat_chow）。在 SELinux 中我可以将这条规则写入策略中。

allow cat cat_chow:food eat;

允许 猫 猫粮：食物 吃；

allow dog dog_chow:food eat;

允许 狗 狗粮：食物 吃；

有了这些规则，内核会允许猫进程去吃打上猫粮标签 cat_chow 的食物，允许狗去吃打上狗粮标签 dog_chow 的食物。

此外，在 SELinux 系统中，由于禁止是默认规则，这意味着，如果狗进程想要去吃猫粮 cat_chow，内核会阻止它。

同理，猫也不允许去接触狗粮。

现实例子

我们将 Apache 进程标为 httpd_t，将 Apache 上下文标为 httpd_sys_content_t 和 httpdsys_content_rw_t。假设我们把信用卡数据存储在 MySQL 数据库中，其标签为 msyqld_data_t。如果一个 Apache 进程被劫持，黑客可以获得 httpd_t 进程的控制权，从而能够去读取 httpd_sys_content_t 文件并向 httpd_sys_content_rw_t 文件执行写操作。但是黑客却不允许去读信用卡数据（mysqld_data_t），即使 Apache 进程是在 root 下运行。在这种情况下 SELinux 减轻了这次闯入的后果。

多类别安全强制

打个比方

上面我们定义了狗进程和猫进程，但是如果你有多个狗进程：Fido 和 Spot，而你想要阻止 Fido 去吃 Spot 的狗粮 dog_chow 怎么办呢?

一个解决方式是创建大量的新类型，如 Fido_dog 和 Fido_dog_chow。但是这很快会变得难以驾驭因为所有的狗都有差不多相同的权限。

为了解决这个问题我们发明了一种新的强制形式，叫做 多类别安全 （ Multi Category Security ） （MCS）。在 MCS 中，我们在狗进程和狗粮的标签上增加了另外一部分标签。现在我们将狗进程标记为 dog:random1(Fido) 和 dog:random2(Spot)。

我们将狗粮标记为 dog_chow:random1(Fido) 和 dog_chow:random2(Spot)。

MCS 规则声明如果类型强制规则被遵守而且该 MCS 随机标签正确匹配，则访问是允许的，否则就会被拒绝。

Fido (dog:random1) 尝试去吃 cat_chow:food 被类型强制拒绝了。

Fido (dog:random1) 允许去吃 dog_chow:random1。

Fido (dog:random1) 去吃 spot(dog_chow:random2)的食物被拒绝。

现实例子

在计算机系统中我们经常有很多具有同样访问权限的进程，但是我们又希望它们各自独立。有时我们称之为 多租户环境 （ multi-tenant environment ） 。最好的例子就是虚拟机。如果我有一个运行很多虚拟机的服务器，而其中一个被劫持，我希望能够阻止它去攻击其它虚拟机和虚拟机镜像。但是在一个类型强制系统中 KVM 虚拟机被标记为 svirt_t 而镜像被标记为 svirt_image_t。 我们允许 svirt_t 可以读/写/删除标记为 svirt_image_t 的上下文。通过使用 libvirt 我们不仅实现了类型强制隔离，而且实现了 MCS 隔离。当 libvirt 将要启动一个虚拟机时，它会挑选出一个 MCS 随机标签如 s0:c1,c2，接着它会将 svirt_image_t:s0:c1,c2 标签分发给虚拟机需要去操作的所有上下文。最终，虚拟机以 svirt_t:s0:c1,c2 为标签启动。因此，SELinux 内核控制 svirt_t:s0:c1,c2 不允许写向 svirt_image_t:s0:c3,c4，即使虚拟机被一个黑客劫持并接管，即使它是运行在 root 下。

我们在 OpenShift 中使用类似的隔离策略。每一个 gear（user/app process）都有相同的 SELinux 类型（openshift_t）（LCTT 译注：gear 为 OpenShift 的计量单位）。策略定义的规则控制着 gear 类型的访问权限，而一个独一无二的 MCS 标签确保了一个 gear 不能影响其他 gear。

请观看下面的视频来看 OpenShift gear 切换到 root 会发生什么。

多级别安全强制

另外一种不经常使用的 SELinux 强制形式叫做 多级别安全 （ Multi Level Security ） （MLS）；它开发于上世纪 60 年代，并且主要使用在受信操作系统上如 Trusted Solaris。

其核心观点就是通过进程使用的数据等级来控制进程。一个 secret 进程不能读取 top secret 数据。

MLS 很像 MCS，除了它在强制策略中增加了支配的概念。MCS 标签必须完全匹配，但一个 MLS 标签可以支配另一个 MLS 标签并且获得访问。

打个比方

不讨论不同名字的狗，我们现在来看不同种类。我们现在有一只格雷伊猎犬和一只吉娃娃。

我们可能想要允许格雷伊猎犬去吃任何狗粮，但是吉娃娃如果尝试去吃格雷伊猎犬的狗粮可能会被呛到。

我们把格雷伊猎犬标记为 dog:Greyhound，把它的狗粮标记为 dog_chow:Greyhound，把吉娃娃标记为 dog:Chihuahua，把它的狗粮标记为 dog_chow:Chihuahua。

使用 MLS 策略，我们可以使 MLS 格雷伊猎犬标签支配吉娃娃标签。这意味着 dog:Greyhound 允许去吃 dog_chow:Greyhound 和 dog_chow:Chihuahua。

但是 dog:Chihuahua 不允许去吃 dog_chow:Greyhound。

当然，由于类型强制， dog:Greyhound 和 dog:Chihuahua 仍然不允许去吃 cat_chow:Siamese，即使 MLS 类型 GreyHound 支配 Siamese。

现实例子

有两个 Apache 服务器：一个以 httpd_t:TopSecret 运行，一个以 httpd_t:Secret 运行。如果 Apache 进程 httpd_t:Secret 被劫持，黑客可以读取 httpd_sys_content_t:Secret 但会被禁止读取 httpd_sys_content_t:TopSecret。

但是如果运行 httpd_t:TopSecret 的 Apache 进程被劫持，它可以读取 httpd_sys_content_t:Secret 数据和 httpd_sys_content_t:TopSecret 数据。

我们在军事系统上使用 MLS，一个用户可能被允许读取 secret 数据，但是另一个用户在同一个系统上可以读取 top secret 数据。

结论

SELinux 是一个功能强大的标签系统，控制着内核授予每个进程的访问权限。最主要的特性是类型强制，策略规则定义的进程访问权限基于进程被标记的类型和客体被标记的类型。也引入了另外两个控制手段，分离有着同样类型进程的叫做 MCS，而 MLS，则允许进程间存在支配等级。

*所有的漫画都来自 Máirín Duffy

作者简介：

Daniel J Walsh - Daniel Walsh 已经在计算机安全领域工作了将近 30 年。Daniel 于 2001 年 8 月加入红帽。

via: https://opensource.com/business/13/11/selinux-policy-guide

作者：Daniel J Walsh 译者：xiaow6 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

为了解决标准的“用户-组-其他/读-写-执行”权限以及访问控制列表的限制以及加强安全机制，美国国家安全局（NSA）设计出一个灵活的 强制访问控制 （ Mandatory Access Control ） （MAC）方法 SELinux（Security Enhanced Linux 的缩写），来限制标准的权限之外的种种权限，在仍然允许对这个控制模型后续修改的情况下，让进程尽可能以最小权限访问或在系统对象（如文件，文件夹，网络端口等）上执行其他操作。

SELinux 和 AppArmor 加固 Linux 安全

另一个流行并且被广泛使用的 MAC 是 AppArmor，相比于 SELinux 它提供更多的特性，包括一个学习模式，可以让系统“学习”一个特定应用的行为，以及通过配置文件设置限制实现安全的应用使用。

在 CentOS 7 中，SELinux 合并进了内核并且默认启用 强制 （ Enforcing ） 模式（下一节会介绍这方面更多的内容），与之不同的是，openSUSE 和 Ubuntu 使用的是 AppArmor 。

在这篇文章中我们会解释 SELinux 和 AppArmor 的本质，以及如何在你选择的发行版上使用这两个工具之一并从中获益。

SELinux 介绍以及如何在 CentOS 7 中使用

Security Enhanced Linux 可以以两种不同模式运行：

• 强制 （ Enforcing ） ：这种情况下，SELinux 基于 SELinux 策略规则拒绝访问，策略规则是一套控制安全引擎的规则。
• 宽容 （ Permissive ） ：这种情况下，SELinux 不拒绝访问，但如果在强制模式下会被拒绝的操作会被记录下来。

SELinux 也能被禁用。尽管这不是它的一个操作模式，不过也是一种选择。但学习如何使用这个工具强过只是忽略它。时刻牢记这一点！

使用 getenforce 命令来显示 SELinux 的当前模式。如果你想要更改模式，使用 setenforce 0（设置为宽容模式）或 setenforce 1（强制模式）。

因为这些设置重启后就失效了，你需要编辑 /etc/selinux/config 配置文件并设置 SELINUX 变量为 enforcing、permissive 或 disabled ，保存设置让其重启后也有效：

如何启用和禁用 SELinux 模式

还有一点要注意，如果 getenforce 返回 Disabled，你得编辑 /etc/selinux/config 配置文件为你想要的操作模式并重启。否则你无法利用 setenforce 设置（或切换）操作模式。

setenforce 的典型用法之一包括在 SELinux 模式之间切换（从强制到宽容或相反）来定位一个应用是否行为不端或没有像预期一样工作。如果它在你将 SELinux 设置为宽容模式正常工作，你就可以确定你遇到的是 SELinux 权限问题。

有两种我们使用 SELinux 可能需要解决的典型案例：

• 改变一个守护进程监听的默认端口。
• 给一个虚拟主机设置 /var/www/html 以外的文档根路径值。

让我们用以下例子来看看这两种情况。

例 1：更改 sshd 守护进程的默认端口

大部分系统管理员为了加强服务器安全首先要做的事情之一就是更改 SSH 守护进程监听的端口，主要是为了阻止端口扫描和外部攻击。要达到这个目的，我们要更改 /etc/ssh/sshd_config 中的 Port 值为以下值（我们在这里使用端口 9999 为例）：

Port 9999

在尝试重启服务并检查它的状态之后，我们会看到它启动失败：

# systemctl restart sshd
# systemctl status sshd

检查 SSH 服务状态

如果我们看看 /var/log/audit/audit.log，就会看到 sshd 被 SELinux 阻止在端口 9999 上启动，因为它是 JBoss 管理服务的保留端口（SELinux 日志信息包含了词语“AVC”，所以应该很容易把它同其他信息区分开来）：

# cat /var/log/audit/audit.log | grep AVC | tail -1

检查 Linux 审计日志

在这种情况下大部分人可能会禁用 SELinux，但我们不这么做。我们会看到有个让 SELinux 和监听其他端口的 sshd 和谐共处的方法。首先确保你有 policycoreutils-python 这个包，执行：

# yum install policycoreutils-python

查看 SELinux 允许 sshd 监听的端口列表。在接下来的图片中我们还能看到端口 9999 是为其他服务保留的，所以我们暂时无法用它来运行其他服务：

# semanage port -l | grep ssh

当然我们可以给 SSH 选择其他端口，但如果我们确定我们不会使用这台机器跑任何 JBoss 相关的服务，我们就可以修改 SELinux 已存在的规则，转而给 SSH 分配那个端口：

# semanage port -m -t ssh_port_t -p tcp 9999

这之后，我们就可以用前一个 semanage 命令检查端口是否正确分配了，即使用 -lC 参数（list custom 的简称）：

# semanage port -lC
# semanage port -l | grep ssh

给 SSH 分配端口

我们现在可以重启 SSH 服务并通过端口 9999 连接了。注意这个更改重启之后依然有效。

例 2：给一个虚拟主机设置 /var/www/html 以外的 文档根路径 （ DocumentRoot ）

如果你需要用除 /var/www/html 以外目录作为 文档根目录 （ DocumentRoot ） 设置一个 Apache 虚拟主机（也就是说，比如 /websrv/sites/gabriel/public_html）：

DocumentRoot “/websrv/sites/gabriel/public_html”

Apache 会拒绝提供内容，因为 index.html 已经被标记为了 default_t SELinux 类型，Apache 无法访问它：

# wget http://localhost/index.html
# ls -lZ /websrv/sites/gabriel/public_html/index.html

被标记为 default\_t SELinux 类型

和之前的例子一样，你可以用以下命令验证这是不是 SELinux 相关的问题：

# cat /var/log/audit/audit.log | grep AVC | tail -1

检查日志确定是不是 SELinux 的问题

要将 /websrv/sites/gabriel/public_html 整个目录内容标记为 httpd_sys_content_t，执行：

# semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

上面这个命令会赋予 Apache 对那个目录以及其内容的读取权限。

最后，要应用这条策略（并让更改的标记立即生效），执行：

# restorecon -R -v /websrv/sites/gabriel/public_html

现在你应该可以访问这个目录了：

# wget http://localhost/index.html

访问 Apache 目录

要获取关于 SELinux 的更多信息，参阅 Fedora 22 中的 SELinux 用户及管理员指南。

AppArmor 介绍以及如何在 OpenSUSE 和 Ubuntu 上使用它

AppArmor 的操作是基于写在纯文本文件中的规则定义，该文件中含有允许权限和访问控制规则。安全配置文件用来限制应用程序如何与系统中的进程和文件进行交互。

系统初始就提供了一系列的配置文件，但其它的也可以由应用程序在安装的时候设置或由系统管理员手动设置。

像 SELinux 一样，AppArmor 以两种模式运行。在 强制 （ enforce ） 模式下，应用被赋予它们运行所需要的最小权限，但在 抱怨 （ complain ） 模式下 AppArmor 允许一个应用执行受限的操作并将操作造成的“抱怨”记录到日志里（/var/log/kern.log，/var/log/audit/audit.log，和其它放在 /var/log/apparmor 中的日志）。

日志中会显示配置文件在强制模式下运行时会产生错误的记录，它们中带有 audit 这个词。因此，你可以在 AppArmor 的 强制 （ enforce ） 模式下运行之前，先在 抱怨 （ complain ） 模式下尝试运行一个应用并调整它的行为。

可以用这个命令显示 AppArmor 的当前状态：

$ sudo apparmor_status

查看 AppArmor 的状态

上面的图片指明配置 /sbin/dhclient，/usr/sbin/，和 /usr/sbin/tcpdump 等处在 强制 （ enforce ） 模式下（在 Ubuntu 下默认就是这样的）。

因为不是所有的应用都包含相关的 AppArmor 配置，apparmor-profiles 包给其它没有提供限制的包提供了配置。默认它们配置在 抱怨 （ complain ） 模式下运行，以便系统管理员能够测试并选择一个所需要的配置。

我们将会利用 apparmor-profiles，因为写一份我们自己的配置已经超出了 LFCS 认证的范围了。但是，由于配置都是纯文本文件，你可以查看并学习它们，为以后创建自己的配置做准备。

AppArmor 配置保存在 /etc/apparmor.d 中。让我们来看看这个文件夹在安装 apparmor-profiles 之前和之后有什么不同：

$ ls /etc/apparmor.d

查看 AppArmor 文件夹内容

如果你再次执行 sudo apparmor_status，你会在 抱怨 （ complain ） 模式看到更长的配置文件列表。你现在可以执行下列操作。

将当前在 强制 （ enforce ） 模式下的配置文件切换到 抱怨 （ complain ） 模式：

$ sudo aa-complain /path/to/file

以及相反的操作（抱怨 –> 强制）：

$ sudo aa-enforce /path/to/file

上面这些例子是允许使用通配符的。举个例子：

$ sudo aa-complain /etc/apparmor.d/*

会将 /etc/apparmor.d 中的所有配置文件设置为 抱怨 （ complain ） 模式，反之

$ sudo aa-enforce /etc/apparmor.d/*

会将所有配置文件设置为 强制 （ enforce ） 模式。

要完全禁用一个配置，在 /etc/apparmor.d/disabled 目录中创建一个符号链接：

$ sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/

要获取关于 AppArmor 的更多信息，参阅官方的 AppArmor wiki 以及 Ubuntu 提供的文档。

总结

在这篇文章中我们学习了一些 SELinux 和 AppArmor 这两个著名的强制访问控制系统的基本知识。什么时候使用两者中的一个或是另一个？为了避免提高难度，你可能需要考虑专注于你选择的发行版自带的那一个。不管怎样，它们会帮助你限制进程和系统资源的访问，以提高你服务器的安全性。

关于本文你有任何的问题，评论，或建议，欢迎在下方发表。不要犹豫，让我们知道你是否有疑问或评论。

via: http://www.tecmint.com/mandatory-access-control-with-selinux-or-apparmor-linux/

作者：Gabriel Cánepa 译者：alim0x 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

回到 Kernel 2.6 时代，那时候引入了一个新的安全系统，用以提供访问控制安全策略的机制。这个系统就是 Security Enhanced Linux (SELinux)，它是由美国国家安全局（NSA）贡献的，它为 Linux 内核子系统引入了一个健壮的 强制控制访问 （ Mandatory Access Control ） 架构。

如果你在之前的 Linux 生涯中都禁用或忽略了 SELinux，这篇文章就是专门为你写的：这是一篇对存在于你的 Linux 桌面或服务器之下的 SELinux 系统的介绍，它能够限制权限，甚至消除程序或守护进程的脆弱性而造成破坏的可能性。

在我开始之前，你应该已经了解的是 SELinux 主要是红帽 Red Hat Linux 以及它的衍生发行版上的一个工具。类似地， Ubuntu 和 SUSE（以及它们的衍生发行版）使用的是 AppArmor。SELinux 和 AppArmor 有显著的不同。你可以在 SUSE，openSUSE，Ubuntu 等等发行版上安装 SELinux，但这是项难以置信的挑战，除非你十分精通 Linux。

说了这么多，让我来向你介绍 SELinux。

DAC vs. MAC

Linux 上传统的访问控制标准是 自主访问控制 （ Discretionary Access Control ） （DAC）。在这种形式下，一个软件或守护进程以 User ID（UID）或 Set owner User ID（SUID）的身份运行，并且拥有该用户的目标（文件、套接字、以及其它进程）权限。这使得恶意代码很容易运行在特定权限之下，从而取得访问关键的子系统的权限。

另一方面， 强制访问控制 （ Mandatory Access Control ） （MAC）基于保密性和完整性强制信息的隔离以限制破坏。该限制单元独立于传统的 Linux 安全机制运作，并且没有超级用户的概念。

SELinux 如何工作

考虑一下 SELinux 的相关概念:

• 主体 （ Subjects ）
• 目标 （ Objects ）
• 策略 （ Policy ）
• 模式 （ Mode ）

当一个 主体 （ Subject ） （如一个程序）尝试访问一个 目标 （ Object ） （如一个文件）， SELinux 安全服务器 （ SELinux Security Server ） （在内核中）从 策略数据库 （ Policy Database ） 中运行一个检查。基于当前的 模式 （ mode ） ，如果 SELinux 安全服务器授予权限，该主体就能够访问该目标。如果 SELinux 安全服务器拒绝了权限，就会在 /var/log/messages 中记录一条拒绝信息。

听起来相对比较简单是不是？实际上过程要更加复杂，但为了简化介绍，只列出了重要的步骤。

模式

SELinux 有三个模式（可以由用户设置）。这些模式将规定 SELinux 在主体请求时如何应对。这些模式是：

• Enforcing （ 强制 ） — SELinux 策略强制执行，基于 SELinux 策略规则授予或拒绝主体对目标的访问
• Permissive （ 宽容 ） — SELinux 策略不强制执行，不实际拒绝访问，但会有拒绝信息写入日志
• Disabled （ 禁用 ） — 完全禁用 SELinux

图 1：getenforce 命令显示 SELinux 的状态是 Enforcing 启用状态。

默认情况下，大部分系统的 SELinux 设置为 Enforcing。你要如何知道你的系统当前是什么模式？你可以使用一条简单的命令来查看，这条命令就是 getenforce。这个命令用起来难以置信的简单（因为它仅仅用来报告 SELinux 的模式）。要使用这个工具，打开一个终端窗口并执行 getenforce 命令。命令会返回 Enforcing、Permissive，或者 Disabled（见上方图 1）。

设置 SELinux 的模式实际上很简单——取决于你想设置什么模式。记住：永远不推荐关闭 SELinux。为什么？当你这么做了，就会出现这种可能性：你磁盘上的文件可能会被打上错误的权限标签，需要你重新标记权限才能修复。而且你无法修改一个以 Disabled 模式启动的系统的模式。你的最佳模式是 Enforcing 或者 Permissive。

你可以从命令行或 /etc/selinux/config 文件更改 SELinux 的模式。要从命令行设置模式，你可以使用 setenforce 工具。要设置 Enforcing 模式，按下面这么做：

1. 打开一个终端窗口
2. 执行 su 然后输入你的管理员密码
3. 执行 setenforce 1
4. 执行 getenforce 确定模式已经正确设置（图 2）

图 2：设置 SELinux 模式为 Enforcing。

要设置模式为 Permissive，这么做：

1. 打开一个终端窗口
2. 执行 su 然后输入你的管理员密码
3. 执行 setenforce 0
4. 执行 getenforce 确定模式已经正确设置（图 3）

图 3：设置 SELinux 模式为 Permissive。

注：通过命令行设置模式会覆盖 SELinux 配置文件中的设置。

如果你更愿意在 SELinux 命令文件中设置模式，用你喜欢的编辑器打开那个文件找到这一行：

SELINUX=permissive

你可以按你的偏好设置模式，然后保存文件。

还有第三种方法修改 SELinux 的模式（通过 bootloader），但我不推荐新用户这么做。

策略类型

SELinux 策略有两种：

• Targeted （ 目标 ） — 只有目标网络进程（dhcpd，httpd，named，nscd，ntpd，portmap，snmpd，squid，以及 syslogd）受保护
• Strict （ 严格 ） — 对所有进程完全的 SELinux 保护

你可以在 /etc/selinux/config 文件中修改策略类型。用你喜欢的编辑器打开这个文件找到这一行：

SELINUXTYPE=targeted

修改这个选项为 targeted 或 strict 以满足你的需求。

检查完整的 SELinux 状态

有个方便的 SELinux 工具，你可能想要用它来获取你启用了 SELinux 的系统的详细状态报告。这个命令在终端像这样运行：

sestatus -v

你可以看到像图 4 那样的输出。

图 4：sestatus -v 命令的输出。

仅是皮毛

和你预想的一样，我只介绍了 SELinux 的一点皮毛。SELinux 的确是个复杂的系统，想要更扎实地理解它是如何工作的，以及了解如何让它更好地为你的桌面或服务器工作需要更加地深入学习。我的内容还没有覆盖到疑难解答和创建自定义 SELinux 策略。

SELinux 是所有 Linux 管理员都应该知道的强大工具。现在已经向你介绍了 SELinux，我强烈推荐你回到 Linux.com（当有更多关于此话题的文章发表的时候）或看看 NSA SELinux 文档 获得更加深入的指南。

LCTT - 相关阅读：鸟哥的 Linux 私房菜——程序管理与 SELinux 初探

via: https://www.linux.com/learn/docs/ldp/883671-an-introduction-to-selinux

作者：Jack Wallen 译者：alim0x 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出