您是否曾经为了社会的福祉而做过艰辛的工作，却没有注意到自己的努力，因为您受益良久，已经习惯了吗？ 这是所有
SELinux社区成员为您所做的工作。
今年2月18日，在很大程度上要归功于他们的工作，全世界从危险
的撞容器漏洞
CVE-2019-5736中获救 。
尽管还有其他使用类型和类别控件的操作系统和其他开放源代码项目，但是很少有默认情况下包含开箱即用的随SELinux配置的组件，并且随时可以使用。 甚至更罕见的是，此配置涵盖所有级别，直到容器编排解决方案为止，公共云便以此为基础。
八年来，红帽OpenShift一直在使用Linux强制访问控制机制，例如类型强制（TE）和多类别安全性（MCS）。 自2011年以来，SELinux已在OpenShift中使用。 Red Hat OpenShift Online是一个公共托管服务，每天有成千上万的开发人员运行容器代码，而SELinux从一开始就被使用。 例如，在您最喜欢的移动运营商的数据中心中使用的OpenShift版本如何？ 实际上，默认情况下，默认情况下，Red Hat OpenShift容器平台中包含SELinux安全模块！ 而且不仅可以打开电源，还可以进行全面配置并随时防御实际威胁。
与其他Kubernetes发行版不同，Red Hat缩小了Linux与安装在其之上的容器编排平台之间的差距。 也就是说，Red Hat OpenShift不仅可以监视而且消除整个堆栈中的安全威胁，而不仅限于一层。 这是默认情况下完成的-从工作的第一天开始。
OpenShift在Red Hat Enterprise Linux中默认使用此配置（您甚至不需要知道它的功能）。 问题不仅仅限于在笔记本电脑上运行setenforce 1，针对租户适用于在一个Kubernetes集群上使用容器的类型和类别的访问控制规则可以扩展到数百个节点，这些节点可以被成千上万的其他租户使用。
考虑一下使用MCS的SELinux配置在一家大型公司中使用几年后的样子，该大公司左右分配OpenShift凭据。 现在想象一下，就像我们在openshift.com上一样，您提供凭据即可登录到OpenShift集群。 SELinux的忠诚度常常因OpenShift解决方案中所做的一切而无法得到认可。 如果您觉得这些天操作系统不是那么重要，请考虑到今年2月，是否已保护您免受CVE-2019-5736漏洞的影响。 在OpenShift中，
CVE-2019-5736从一开始就
受到保护 ，您
现在就可以继续使用此解决方案。
SELinux标志
Red Hat OpenShift中实现的最有效的默认安全功能之一是增强安全性的Linux（SELinux）。 SELinux是Linux内核安全模块，提供基于安全策略的访问控制。 SELinux的工作方式是为操作系统的所有进程和对象分配标签（名称）。 因此，对内核操作中涉及的每个元素都进行了标记和分类，然后根据现有规则集授予其访问权限。
策略规则定义了标记的进程和标记的对象之间的关系。 用户在策略中定义的规则在内核级别应用。 默认情况下，不允许的任何东西都会被自动拒绝-类似于防火墙，拒绝访问未配置显式权限的所有进程。 下图说明了简单的用例。
想象一下一个系统，您需要在其中定义诸如猫和狗之类的对象的类型。 猫和狗是过程的类型。
*所有图纸均由MáirínDuffy提供流程将与之交互的对象类别是feed。 添加供稿类型：cat_chow和dog_chow（Ohm-nom-nom）。
我们设置了允许狗吃狗粮（dog_chow）和允许猫吃猫粮（cat_chow）的权限。 我们将这些权限写为SELinux策略规则：
allow cat cat_chow:food eat; allow dog dog_chow:food eat;
根据这些规则，将允许“ cat”过程在内核级别使用标有cat_chow的食物进餐，而允许狗食用标有dog_chow的食物。
但是我们记得在SELinux中，默认情况下，所有内容都是禁止的。 因此，如果狗尝试吃cat_chow，则核心不允许。
这是类型控制，在保护主机系统免受容器进程的侵害中起主要作用。 容器进程只能从/ usr目录读取和运行文件，并且只能将数据写入容器文件。 此限制可靠地保护了主机免受容器侵害，但并没有保护某些容器免受其他容器侵害，因为它们都标记有相同的类型。 为了彼此保护容器，您将需要实现MCS标签控制。
MCS不会尾巴拉猫
MCS的使用与
CVE-2019-5736中OpenShift的保护没有直接关系，但是熟悉本主题以帮助更好地理解在OpenShift中使用SELinux的原理很有用。 从用户或系统管理员的角度分配MCS标签非常简单。 您只需要配置一组作为简单文本标签的类别（例如，Fido或Spot），然后向其中添加用户。 系统管理员首先设置类别，然后将用户添加到其中，然后用户可以根据需要使用这些标签。 这很方便，因为MCS允许您使用标准的SELinux标记来管理对象。 让我们再次从上面的示例转向虚拟系统。
添加将应用于dog进程和dog_chow提要的标签的另一部分。 将过程“ dog”分配给dog：random1（Fido）和dog：random2（Spot）。
让我们为狗粮分配dog_chow：random1（Fido）和dog_chow：random2（Spot）标签。
根据MCS的操作原理，如果强制控制的规则通过类型满足且任意MCS标签完全匹配，则允许访问，而在所有其他情况下，将拒绝访问。
Fido（狗：random1）尝试吃cat_chow：由于强制类型控制，食物将被拒绝。
纵深防御
OpenShift使用的默认SELinux安全模块是深度防御的主要示例。 与许多其他基于Kubernetes的平台一样，OpenShift使用
SCC / PSP策略来禁止以root特权运行容器。 此限制还可以防止
CVE-2019-5736的侵害 。 在OpenShift中，默认情况下阻止root用户拥有的容器，但是
可以更改此参数。 即使允许容器以root用户身份运行，OpenShift中的标准SELinux配置仍然可以防止
CVE-2019-5736的侵害 。 在这种情况下，这实际上是另一种保护措施，而且与OpenShift中唯一的保护措施相距甚远。 可以在文档
10容器安全级别中找到更多信息。
有关
CVE-2019-5736的更多信息，包括用于容器运行时的Red Hat Enterprise Linux补丁，请参阅
Red Hat漏洞回顾 。