A Review for "Selinux System Administration" by Sven Vermeulen

说实在的关于Sven Vermeulen的“SELinux系统管理”（SELinux System Administration）我会写什么样的短评？

我不能写作详细的评论，因为我没有从头到尾阅读整本书。

我不能写作内容提要，因为这本书涉及的领域很宽，提到巨多不同的话题。

我甚至都不会写清晰的HOWTO“如何使用SELinux，为了升级自己服务器的安全性”，因为，一则本任务太严重的依赖服务器的结构本身，其次因为这本书不包含所需要的信息。

这本书到底是关于什么的内容？

我上次写短评遇到这种困难的时候是三年前。 那时我在尝试写作我对“INCOSE Systems Engineering Handbook”的观点。

一方面本书不包含坑爹内容，包括所有需要的，但是另一方面很难解释“它到底是关于什么”。

可是，这一次我的问题不是在于这本书本身，而是在于它要讲解的话题。

SELinux是很复杂的客体。 并且复杂在细节、容量方面，而不在算法复杂度方面。 SELinux有很多细节、特性，因为它被开发很久了。 一部分特性是为了补偿原来的模型的缺点而存在，一部分是为了让它跟其它的Linux分系统同步而存在，一部分本来就是不顺利的设计。

也可以说此文本任务 – 不完全是为一本书的观点，而更多的是我尝试讲解“刚刚足够避免因系统坏了而纳闷的知识”, 并不是尝试评估书的内容品质。

大部分SELinux说明书从“SELinux是Linux内核安全性模块之一”开始。 这里“模块”不是“可以在内核加载客体文件”，而是“实现某些接口的代码，跟某些其他代码可以互换”。 从某一方面来说这个是实话，因为除了SELinux以外，还有其他的“安全性模块”，比如AppArmor.

反之，只有内核代码不能完全实现整个SELinux，还需要用户等代码。 而且除了最明显的的调试SELinux的方法（通过GNU Coreutils）以外，PAM，systemd，dbus，ipsec等工具都有某些SELinux支持。

什么鬼？这是什么样的怪物？

可是SELinux确实是这样，从头到尾贯穿整个系统。 因为如果不是这样，就不能构造无所不包的安全系统。

这到底是什么？

大概的说，SELinux是专门被发明的规范化系统，被用来使用一种很详细的语言描述“谁被允许做什么”。

这个定义也不是很容易理解吗？

换句话，Linux内核有一个“窄处”。 在该“窄处”，“某事”，被标为“某标签”，在“某客体”上，执行“某操作”。 同时Linux内核会判断是否允许这个操作。

还是很抽象吗？

我举个例子。

大部分时间“某事”是一个进程。 这里还有一个微妙的事情，因为我们一般情况下要分辨系统进程和用户进程，虽然理论上它们没有区别，都是程序。 例如在这种情况下，我们至少会遇到“进程标签”（“系统的”还是“用户的”）。 但结果是，SELinux开发者，花费很长时间开发之后，却让管理员遇到：“用户标签”，“角色标签”，“进程标签”。 但是，不要认为这三个标签有固定的定义，比如不要认为“用户标签”有相符的系统用户名，或“进程标签”有相符的系统服务名，虽然在RedHat系统上确实是这样。

典型的“客体”是一个文件。 它也具有三个标签，但是对于文件来说，这标签的意义更是令人困惑。 在很多案例中，只有第三个标签“上下文”有某些意义。 标签文件是在文件系统"扩展属性"中存储的， 但并不完全是这样。

不幸的是，这个“并不完全是这样”贯穿整个SELinux分系统。 事实上，标签来自专门设置的文件夹，/etc/selinux，并且还有特殊的命令，叫做“restorecon”，把在该文件夹定义的标签分配在全部文件上。

为什么需要这么做？ 难道是由于速度的原因？ 或者为了让用户改换文件标签，但不允许它改变/etc/selinux内的文件？

其他的客体类型会是…任何物! 比如，tcp-ip端口、ipsec网络包、dbus服务。 在最后一个例子，内核不会参加SELinux验证，但特殊代码库会。

然而，连内核和特殊代码库都应该有某些方法理解什么被允许和什么被禁止。 （在SELinux默认设置中，所有的事情都是被禁止的，所以很容易搞错，禁止自己管理系统。） 每个激活SELinux的系统一般都有/etc/selinux目录，含有很多政策文件，在此文件某些“政策写者”应该使用专门的语言很详细的，一步一步，一文件一文件，一用户一用户，说明准确的标签互动。

天真的年轻人，我开始阅读Sven Vermeulen的书的时候，我以为，读完一章导语之后，我大部分时间会用来写作几个“教练政策”。

并非如此。讲解写作政策的话，这个Sven Vermeulen还有第二本书籍—SELinux Cookbook—几乎完全针对写作政策。 虽然我在这本“短评”中说“专门的语言”，但是事实上这本书还提到了其他两个不同的政策语言。 非常疲劳的过程，该过程唯一的好处是这三个语言之一与Lisp相似。

事实上没有人自己写这种政策，除了很少的例子以外。 大部分政策通过两个方法来到系统：要么RedHat工程师已经为你提供政策包，那只需要安装该政策包，（并且查看政策代码不是那么简单！政策包是二进制文件！），要么你会使用魔法命令“audit2allow”, 基于最近的违反安全政策的案例，它会为你生成允许性政策。 这个政策既可能不准，又可能效率低，但是它会帮助你“立刻启动”你的服务。

一般来说，还有seinfo和sesearch命令，它们能检查存在的政策规定，但是我认为，调试SELinux政策非常的难。

总之, 如果大部分系统管理员不写作政策代码，并且这本书只包括一个关于政策的章节，那么这本书到底是关于什么？

它讲解了很多在使用SELinux可以遇到的细节。

比如“selinux boolean”。 这是一些（在政策里被定义的）变量，按照该变量，政策会改变自己的行为。 它们有什么意义？ 为什么不可以直接写另外一个政策呢？ 表面上，是因为默认的政策是一个二进制模块，而且普通的系统管理员不会写政策。

此外，这本书还讲解了如何全部关闭或者打开SELinux的分系统，或者如何激活permissive模式。 该模式下SELinux会记录违反案例，但是不会阻止。

讨论文件上下文的话，matchpathcon、chcon、runcon、让用户监视，检查和验证路径标签等命令，被讲解的比较好。

某些分系统帮助内核在不同的客体上设定准确的上下文，其中有systemd, dbus, PAM都是Linux内核没办法直接触碰到的同等分系统。 这本书也比较详细的描述了此互动。

整一章描述SELinux和Docker或libvirt的合作。 最初看来，这似乎是冗余的，因为毕竟docker和libvirt中包括依靠系统层隔离的安全性用法，即使是为了避免太详细的设定安全情况。 不过，知道此功能存在也有用。

有一个事情，这本书基本不覆盖。 是跟安卓相关的SELinux用法。 基于显性的判断，安卓是第二个SELinux用例，但是基于设备数可能是第一个。 不过，这本书关于安卓的内容介绍非常的少，因此这个知识需要在其它书中查阅。

总结，根据我的猜测，为了完全理解SELinux,需要至少阅读5本书：

1. SELinux System Administration by Sven Vermeulen
2. SELinux Cookbook by Sven Vermeulen
3. SELinux Notebook by SELinux community
4. RedHat SELinux Administration Guide
5. Android SELinux Documentation

很多？确实很多。

最后，我要总结本“准”短评，我应该说，我没有找到在小范围内就可以开始使用SELinux的方法。 也许，作为幼儿园的案例，你可以隔离化nginx,把它安装在标准的Redhat系统上，然后打开默认的政策。 从而在自己的简历上加一行“有SELinux的经验”。 但是我不会把这个算作良好的成就。