容器可用安全策略

本节是第六部分“安全篇”的第二篇，在这个部分，我将用四篇内容为你介绍包括镜像，容器和 Linux 内核的 LSM 等内容。上篇，我为你介绍了容器镜像安全相关的内容。本篇，我们将重点放在容器安全上。

在第一部分“容器篇”中，我已经带你深入剖析了 Docker 容器的本质，以及其所用到的核心技术 cgroups 和 namespace。

在上一篇中，我为你介绍了镜像安全相关的内容，分享了一些思路及方法，本篇，我们将容器放在容器安全上。

那么容器可能会有哪些安全问题呢？这就要从 Linux 的权限说起了。

Linux 的权限模型

Linux 的权限模型在早期只分为两类：特权进程和非特权进程。

• 特权进程：有效 UID 为 0（一般也称为超级用户或者 root 用户）的进程，特权进程可以绕过所有的内核权限检查。
• 非特权进程：有效 UID 为非 0 的进程，非特权进程需要根据进程的凭证（有效 UID、有效 GID 等）进行相应的权限检查。

在这种模型下，很容易发生权限失控的问题。如果是一般用户想要提升权限执行某些命令的话，通常有两种方法：一种是使用 sudo 来完成，但如果服务器上有很多用户，且这些用户需要有不同的权限控制，那就会很繁琐；另一种是使用 SUID 的方式，允许一般用户来运行一个归属于 root 的文件，并同时具备 root 的权限，但这种情况下便更加不容易控制用户的权限了。

所以从 Linux 2.2 开始便将与超级用户相关联的特权划分为了不同的单元，称之为 capabilities 并且可以独