了解如何使用 Podman 在单独的用户空间运行容器。

Podman 是 libpod 库的一部分，使用户能够管理 pod、容器和容器镜像。在我的上一篇文章中，我写过将 Podman 作为一种更安全的运行容器的方式。在这里，我将解释如何使用 Podman 在单独的用户命名空间中运行容器。

作为分离容器的一个很棒的功能，我一直在思考 用户命名空间 user namespace ，它主要是由 Red Hat 的 Eric Biederman 开发的。用户命名空间允许你指定用于运行容器的用户标识符（UID）和组标识符（GID）映射。这意味着你可以在容器内以 UID 0 运行，在容器外以 UID 100000 运行。如果容器进程逃逸出了容器，内核会将它们视为以 UID 100000 运行。不仅如此，任何未映射到用户命名空间的 UID 所拥有的文件对象都将被视为 nobody 所拥有（UID 是 65534， 由 kernel.overflowuid 指定），并且不允许容器进程访问，除非该对象可由“其他人”访问（即世界可读/可写）。

如果你拥有一个权限为 660 的属主为“真实” root 的文件，而当用户命名空间中的容器进程尝试读取它时，会阻止它们访问它，并且会将该文件视为 nobody 所拥有。

示例

以下是它是如何工作的。首先，我在 root 拥有的系统中创建一个文件。

$ sudo bash -c "echo Test > /tmp/test"
$ sudo chmod 600 /tmp/test
$ sudo ls -l /tmp/test
-rw-------. 1 root root 5 Dec 17 16:40 /tmp/test

接下来，我将该文件卷挂载到一个使用用户命名空间映射 0:100000:5000 运行的容器中。

$ sudo podman run -ti -v /tmp/test:/tmp/test:Z --uidmap 0:100000:5000 fedora sh
# id
uid=0(root) gid=0(root) groups=0(root)
# ls -l /tmp/test
-rw-rw----. 1 nobody nobody 8 Nov 30 12:40 /tmp/test
# cat /tmp/test
cat: /tmp/test: Permission denied

上面的 --uidmap 设置告诉 Podman 在容器内映射一系列的 5000 个 UID，从容器外的 UID 100000 开始的范围（100000-104999）映射到容器内 UID 0 开始的范围（0-4999）。在容器内部，如果我的进程以 UID 1 运行，则它在主机上为 100001。

由于实际的 UID=0 未映射到容器中，因此 root 拥有的任何文件都将被视为 nobody 所拥有。即使容器内的进程具有 CAP_DAC_OVERRIDE 能力，也无法覆盖此种保护。DAC_OVERRIDE 能力使得 root 的进程能够读/写系统上的任何文件，即使进程不是 root 用户拥有的，也不是全局可读或可写的。

用户命名空间的功能与宿主机上的功能不同。它们是命名空间的功能。这意味着我的容器的 root 只在容器内具有功能 —— 实际上只有该范围内的 UID 映射到内用户命名空间。如果容器进程逃逸出了容器，则它将没有任何非映射到用户命名空间的 UID 之外的功能，这包括 UID=0。即使进程可能以某种方式进入另一个容器，如果容器使用不同范围的 UID，它们也不具备这些功能。

请注意，SELinux 和其他技术还限制了容器进程破开容器时会发生的情况。

使用 podman top 来显示用户名字空间

我们在 podman top 中添加了一些功能，允许你检查容器内运行的进程的用户名，并标识它们在宿主机上的真实 UID。

让我们首先使用我们的 UID 映射运行一个 sleep 容器。

$ sudo podman run --uidmap 0:100000:5000 -d fedora sleep 1000

现在运行 podman top：

$ sudo podman top --latest user huser
USER   HUSER
root   100000

$ ps -ef | grep sleep
100000   21821 21809  0 08:04 ?         00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000

注意 podman top 报告用户进程在容器内以 root 身份运行，但在宿主机（HUSER）上以 UID 100000 运行。此外，ps 命令确认 sleep 过程以 UID 100000 运行。

现在让我们运行第二个容器，但这次我们将选择一个单独的 UID 映射，从 200000 开始。

$ sudo podman run --uidmap 0:200000:5000 -d fedora sleep 1000
$ sudo podman top --latest user huser
USER   HUSER
root   200000

$ ps -ef | grep sleep
100000   21821 21809  0 08:04 ?         00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000
200000   23644 23632  1 08:08 ?         00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 1000

请注意，podman top 报告第二个容器在容器内以 root 身份运行，但在宿主机上是 UID=200000。

另请参阅 ps 命令，它显示两个 sleep 进程都在运行：一个为 100000，另一个为 200000。

这意味着在单独的用户命名空间内运行容器可以在进程之间进行传统的 UID 分离，而这从一开始就是 Linux/Unix 的标准安全工具。

用户名字空间的问题

几年来，我一直主张用户命名空间应该作为每个人应该有的安全工具，但几乎没有人使用过。原因是没有任何文件系统支持，也没有一个 移动文件系统 shifting file system 。

在容器中，你希望在许多容器之间共享基本镜像。上面的每个示例中使用了 Fedora 基本镜像。Fedora 镜像中的大多数文件都由真实的 UID=0 拥有。如果我在此镜像上使用用户名称空间 0:100000:5000 运行容器，默认情况下它会将所有这些文件视为 nobody 所拥有，因此我们需要移动所有这些 UID 以匹配用户名称空间。多年来，我想要一个挂载选项来告诉内核重新映射这些文件 UID 以匹配用户命名空间。上游内核存储开发人员还在继续研究，在此功能上已经取得一些进展，但这是一个难题。

由于由 Nalin Dahyabhai 领导的团队开发的自动 chown 内置于容器/存储中，Podman 可以在同一镜像上使用不同的用户名称空间。当 Podman 使用容器/存储，并且 Podman 在新的用户命名空间中首次使用一个容器镜像时，容器/存储会 “chown”（如，更改所有权）镜像中的所有文件到用户命名空间中映射的 UID 并创建一个新镜像。可以把它想象成一个 fedora:0:100000:5000 镜像。

当 Podman 在具有相同 UID 映射的镜像上运行另一个容器时，它使用“预先 chown”的镜像。当我在0:200000:5000 上运行第二个容器时，容器/存储会创建第二个镜像，我们称之为 fedora:0:200000:5000。

请注意，如果你正在执行 podman build 或 podman commit 并将新创建的镜像推送到容器注册库，Podman 将使用容器/存储来反转该移动，并将推送所有文件属主变回真实 UID=0 的镜像。

这可能会导致在新的 UID 映射中创建容器时出现真正的减速，因为 chown 可能会很慢，具体取决于镜像中的文件数。此外，在普通的 OverlayFS 上，镜像中的每个文件都会被复制。普通的 Fedora 镜像最多可能需要 30 秒才能完成 chown 并启动容器。

幸运的是，Red Hat 内核存储团队（主要是 Vivek Goyal 和 Miklos Szeredi）在内核 4.19 中为 OverlayFS 添加了一项新功能。该功能称为“仅复制元数据”。如果使用 metacopy=on 选项来挂载层叠文件系统，则在更改文件属性时，它不会复制较低层的内容；内核会创建新的 inode，其中包含引用指向较低级别数据的属性。如果内容发生变化，它仍会复制内容。如果你想试用它，可以在 Red Hat Enterprise Linux 8 Beta 中使用此功能。

这意味着容器 chown 可能在两秒钟内发生，并且你不会倍增每个容器的存储空间。

这使得像 Podman 这样的工具在不同的用户命名空间中运行容器是可行的，大大提高了系统的安全性。

前瞻

我想向 Podman 添加一个新选项，比如 --userns=auto，它会为你运行的每个容器自动选择一个唯一的用户命名空间。这类似于 SELinux 与单独的多类别安全（MCS）标签一起使用的方式。如果设置环境变量 PODMAN_USERNS=auto，则甚至不需要设置该选项。

Podman 最终允许用户在不同的用户名称空间中运行容器。像 Buildah 和 CRI-O 这样的工具也可以利用用户命名空间。但是，对于 CRI-O，Kubernetes 需要了解哪个用户命名空间将运行容器引擎，上游正在开发这个功能。

在我的下一篇文章中，我将解释如何在用户命名空间中将 Podman 作为非 root 用户运行。

via: https://opensource.com/article/18/12/podman-and-user-namespaces

作者：Daniel J Walsh 选题：lujun9972 译者：wxy 校对：wxy

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

Podman 使用传统的 fork/exec 模型（相对于客户端/服务器模型）来运行容器。

在进入本文的主要主题 Podman 和容器之前，我需要了解一点 Linux 审计功能的技术。

什么是审计？

Linux 内核有一个有趣的安全功能，叫做审计。它允许管理员在系统上监视安全事件，并将它们记录到audit.log 中，该文件可以本地存储或远程存储在另一台机器上，以防止黑客试图掩盖他的踪迹。

/etc/shadow 文件是一个经常要监控的安全文件，因为向其添加记录可能允许攻击者获得对系统的访问权限。管理员想知道是否有任何进程修改了该文件，你可以通过执行以下命令来执行此操作：

# auditctl -w /etc/shadow

现在让我们看看当我修改了 /etc/shadow 文件会发生什么：

# touch /etc/shadow 
# ausearch -f /etc/shadow -i -ts recent

type=PROCTITLE msg=audit(10/10/2018 09:46:03.042:4108) : proctitle=touch /etc/shadow type=SYSCALL msg=audit(10/10/2018 09:46:03.042:4108) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb17f6704 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=2712 pid=3727 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=touch exe=/usr/bin/touch subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)`

审计记录中有很多信息，但我重点注意到它记录了 root 修改了 /etc/shadow 文件，并且该进程的审计 UID（auid）的所有者是 dwalsh。

内核修改了这个文件了么？

跟踪登录 UID

登录 UID（loginuid），存储在 /proc/self/loginuid 中，它是系统上每个进程的 proc 结构的一部分。该字段只能设置一次；设置后，内核将不允许任何进程重置它。

当我登录系统时，登录程序会为我的登录过程设置 loginuid 字段。

我（dwalsh）的 UID 是 3267。

$ cat /proc/self/loginuid
3267

现在，即使我变成了 root，我的登录 UID 仍将保持不变。

$ sudo cat /proc/self/loginuid
3267

请注意，从初始登录过程 fork 并 exec 的每个进程都会自动继承 loginuid。这就是内核知道登录的人是 dwalsh 的方式。

容器

现在让我们来看看容器。

sudo podman run fedora cat /proc/self/loginuid
3267

甚至容器进程也保留了我的 loginuid。 现在让我们用 Docker 试试。

sudo docker run fedora cat /proc/self/loginuid 
4294967295

为什么不一样？

Podman 对于容器使用传统的 fork/exec 模型，因此容器进程是 Podman 进程的后代。Docker 使用客户端/服务器模型。我执行的 docker 命令是 Docker 客户端工具，它通过客户端/服务器操作与 Docker 守护进程通信。然后 Docker 守护程序创建容器并处理 stdin/stdout 与 Docker 客户端工具的通信。

进程的默认 loginuid（在设置 loginuid 之前）是 4294967295（LCTT 译注：2 ³² - 1）。由于容器是 Docker 守护程序的后代，而 Docker 守护程序是 init 系统的子代，所以，我们看到 systemd、Docker 守护程序和容器进程全部具有相同的 loginuid：4294967295，审计系统视其为未设置审计 UID。

cat /proc/1/loginuid 
4294967295

怎么会被滥用？

让我们来看看如果 Docker 启动的容器进程修改 /etc/shadow 文件会发生什么。

$ sudo docker run --privileged -v /:/host fedora touch /host/etc/shadow 
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:27:20.055:4569) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:27:20.055:4569) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb6973f50 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11863 pid=11882 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=touch exe=/usr/bin/coreutils subj=system_u:system_r:spc_t:s0 key=(null)

在 Docker 情形中，auid 是未设置的（4294967295）；这意味着安全人员可能知道有进程修改了 /etc/shadow 文件但身份丢失了。

如果该攻击者随后删除了 Docker 容器，那么在系统上谁修改 /etc/shadow 文件将没有任何跟踪信息。

现在让我们看看相同的场景在 Podman 下的情况。

$ sudo podman run --privileged -v /:/host fedora touch /host/etc/shadow 
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:23:41.659:4530) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:23:41.659:4530) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fffdffd0f34 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11671 pid=11683 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=3 comm=touch exe=/usr/bin/coreutils subj=unconfined_u:system_r:spc_t:s0 key=(null)

由于它使用传统的 fork/exec 方式，因此 Podman 正确记录了所有内容。

这只是观察 /etc/shadow 文件的一个简单示例，但审计系统对于观察系统上的进程非常有用。使用 fork/exec 容器运行时（而不是客户端/服务器容器运行时）来启动容器允许你通过审计日志记录保持更好的安全性。

最后的想法

在启动容器时，与客户端/服务器模型相比，fork/exec 模型还有许多其他不错的功能。例如，systemd 功能包括：

• SD_NOTIFY：如果将 Podman 命令放入 systemd 单元文件中，容器进程可以通过 Podman 返回通知，表明服务已准备好接收任务。这是在客户端/服务器模式下无法完成的事情。
• 套接字激活：你可以将连接的套接字从 systemd 传递到 Podman，并传递到容器进程以便使用它们。这在客户端/服务器模型中是不可能的。

在我看来，其最好的功能是作为非 root 用户运行 Podman 和容器。这意味着你永远不会在宿主机上授予用户 root 权限，而在客户端/服务器模型中（如 Docker 使用的），你必须打开以 root 身份运行的特权守护程序的套接字来启动容器。在那里，你将受到守护程序中实现的安全机制与宿主机操作系统中实现的安全机制的支配 —— 这是一个危险的主张。

via: https://opensource.com/article/18/10/podman-more-secure-way-run-containers

作者：Daniel J Walsh 选题：lujun9972 译者：wxy 校对：wxy

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

你所需了解的容器如何工作的知识。

现在人们严重过度使用了“容器”这个术语。另外，对不同的人来说，它可能会有不同的含义，这取决于上下文。

传统的 Linux 容器只是系统上普通的进程。一组进程与另外一组进程是相互隔离的，实现方法包括：资源限制（控制组 [cgoups]）、Linux 安全限制（文件权限，基于 Capability 的安全模块、SELinux、AppArmor、seccomp 等）还有名字空间（进程 ID、网络、挂载等）。

如果你启动一台现代 Linux 操作系统，使用 cat /proc/PID/cgroup 命令就可以看到该进程是属于一个控制组的。还可以从 /proc/PID/status 文件中查看进程的 Capability 信息，从 /proc/self/attr/current 文件中查看进程的 SELinux 标签信息，从 /proc/PID/ns 目录下的文件查看进程所属的名字空间。因此，如果把容器定义为带有资源限制、Linux 安全限制和名字空间的进程，那么按照这个定义，Linux 操作系统上的每一个进程都在一个容器里。因此我们常说 Linux 就是容器，容器就是 Linux。而容器运行时是这样一种工具，它调整上述资源限制、安全限制和名字空间，并启动容器。

Docker 引入了容器镜像的概念，镜像是一个普通的 TAR 包文件，包含了：

• rootfs（容器的根文件系统）：一个目录，看起来像是操作系统的普通根目录（/），例如，一个包含 /usr, /var, /home 等的目录。
• JSON 文件（容器的配置）：定义了如何运行 rootfs；例如，当容器启动的时候要在 rootfs 里运行什么命令（CMD）或者入口（ENTRYPOINT），给容器定义什么样的环境变量（ENV），容器的工作目录（WORKDIR）是哪个，以及其他一些设置。

Docker 把 rootfs 和 JSON 配置文件打包成基础镜像。你可以在这个基础之上，给 rootfs 安装更多东西，创建新的 JSON 配置文件，然后把相对于原始镜像的不同内容打包到新的镜像。这种方法创建出来的是分层的镜像。

开放容器计划 Open Container Initiative （OCI）标准组织最终把容器镜像的格式标准化了，也就是 镜像规范 OCI Image Specification （OCI）。

用来创建容器镜像的工具被称为容器镜像构建器。有时候容器引擎做这件事情，不过可以用一些独立的工具来构建容器镜像。

Docker 把这些容器镜像（tar 包）托管到 web 服务中，并开发了一种协议来支持从 web 拉取镜像，这个 web 服务就叫 容器仓库 container registry 。

容器引擎是能从镜像仓库拉取镜像并装载到容器存储上的程序。容器引擎还能启动容器运行时（见下图）。

容器存储一般是 写入时复制 copy-on-write （COW）的分层文件系统。从容器仓库拉取一个镜像时，其中的 rootfs 首先被解压到磁盘。如果这个镜像是多层的，那么每一层都会被下载到 COW 文件系统的不同分层。 COW 文件系统保证了镜像的每一层独立存储，这最大化了多个分层镜像之间的文件共享程度。容器引擎通常支持多种容器存储类型，包括 overlay、devicemapper、btrfs、aufs 和 zfs。

容器引擎将容器镜像下载到容器存储中之后，需要创建一份容器运行时配置，这份配置是用户/调用者的输入和镜像配置的合并。例如，容器的调用者可能会调整安全设置，添加额外的环境变量或者挂载一些卷到容器中。

容器运行时配置的格式，和解压出来的 rootfs 也都被开放容器计划 OCI 标准组织做了标准化，称为 OCI 运行时规范。

最终，容器引擎启动了一个容器运行时来读取运行时配置，修改 Linux 控制组、安全限制和名字空间，并执行容器命令来创建容器的 PID 1 进程。至此，容器引擎已经可以把容器的标准输入/标准输出转给调用方，并控制容器了（例如，stop、start、attach）。

值得一提的是，现在出现了很多新的容器运行时，它们使用 Linux 的不同特性来隔离容器。可以使用 KVM 技术来隔离容器（想想迷你虚拟机），或者使用其他虚拟机监视器策略（例如拦截所有从容器内的进程发起的系统调用）。既然我们有了标准的运行时规范，这些工具都能被相同的容器引擎来启动。即使在 Windows 系统下，也可以使用 OCI 运行时规范来启动 Windows 容器。

容器编排器是一个更高层次的概念。它是在多个不同的节点上协调容器执行的工具。容器编排工具通过和容器引擎的通信来管理容器。编排器控制容器引擎做容器的启动和容器间的网络连接，它能够监控容器，在负载变高的时候进行容器扩容。

via: https://opensource.com/article/18/8/sysadmins-guide-containers

作者：Daniel J Walsh 选题：lujun9972 译者：belitex 校对：wxy

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

容器在过去几年内取得很大的进展。现在我们来回顾它发展的时间线。

Linux 容器是如何演变的

在过去几年内，容器不仅成为了开发者们热议的话题，还受到了企业的关注。持续增长的关注使得在它的安全性、可扩展性以及互用性等方面的需求也得以增长。满足这些需求需要很大的工程量，下面我们讲讲在红帽这样的企业级这些工程是如何发展的。

我在 2013 年秋季第一次遇到 Docker 公司（Docker.io）的代表，那时我们在设法使 Red Hat Enterprise Linux (RHEL) 支持 Docker 容器（现在 Docker 项目的一部分已经更名为 Moby）的运行。在移植过程中，我们遇到了一些问题。处理容器镜像分层所需的写时拷贝（COW）文件系统成了我们第一个重大阻碍。Red Hat 最终贡献了一些 COW 文件系统实现，包括 Device Mapper、btrf，以及 OverlayFS 的第一个版本。在 RHEL 上，我们默认使用 Device Mapper， 但是我们在 OverlayFS 上也已经取得了很大进展。

我们在用于启动容器的工具上遇到了第二个主要障碍。那时的上游 docker 使用 LXC 工具来启动容器，然而我们不想在 RHEL 上支持 LXC 工具集。而且在与上游 docker 合作之前，我们已经与 libvrit 团队携手构建了 virt-sandbox 工具，它使用 libvrit-lxc 来启动容器。

在那时，红帽里有员工提到一个好办法，换掉 LXC 工具集而添加桥接器，以便 docker 守护进程通过 libvirt-lxc 与 libvirt 通讯来启动容器。这个方案也有一些顾虑。考虑下面这个例子，使用 Docker 客户端（docker-cli）来启动容器，各层调用会在容器进程（pid1OfContainer）之前依次启动：

docker-cli → docker-daemon → libvirt-lxc → pid1OfContainer

我不是很喜欢这个方案，因为它在启动容器的工具与最终的容器进程之间有两个守护进程。

我的团队与上游 docker 开发者合作实现了一个原生的 Go 编程语言 版本的容器运行时，叫作 libcontainer。这个库作为 [OCI 运行时规范]的最初版实现与 runc 一同发布。

docker-cli → docker-daemon @ pid1OfContainer

大多数人误认为当他们执行一个容器时，容器进程是作为 docker-cli 的子进程运行的。实际上他们执行的是一个客户端/服务端请求操作，容器进程是在一个完全单独的环境作为子进程运行的。这个客户端/服务端请求会导致不稳定性和潜在的安全问题，而且会阻碍一些实用特性的实现。举个例子，systemd 有个叫做套接字唤醒的特性，你可以将一个守护进程设置成仅当相应的套结字被连接时才启动。这意味着你的系统可以节约内存并按需执行服务。套结字唤醒的工作原理是 systemd 代为监听 TCP 套结字，并在数据包到达套结字时启动相应的服务。一旦服务启动完毕，systemd 将套结字交给新启动的守护进程。如果将守护进程运行在基于 docker 的容器中就会出现问题。systemd 的 unit 文件通过 Docker CLI 执行容器，然而这时 systemd 却无法简单地经由 Docker CLI 将套结字转交给 Docker 守护进程。

类似这样的问题让我们意识到我们需要一个运行容器的替代方案。

容器编排问题

上游的 docker 项目简化了容器的使用过程，同时也是一个绝佳的 Linux 容器学习工具。你可以通过一条简单的命令快速地体验如何启动一个容器，例如运行 docker run -ti fedora sh 然后你就立即处于一个容器之中。

当开始把许多容器组织成一个功能更为强大的应用时，你才能体会到容器真正的能力。但是问题在于伴随多容器应用而来的高复杂度使得简单的 Docker 命令无法胜任编排工作。你要如何管理容器应用在有限资源的集群节点间的布局与编排？如何管理它们的生命周期等等？

在第一届 DockerCon，至少有 7 种不同的公司/开源项目展示了其容器的编排方案。红帽演示了 OpenShift 的 geard 项目，它基于 OpenShift v2 的容器（叫作 gears）。红帽觉得我们需要重新审视容器编排，而且可能要与开源社区的其他人合作。

Google 则演示了 Kubernetes 容器编排工具，它来源于 Google 对其自内部架构进行编排时所积累的知识经验。OpenShift 决定放弃 Gear 项目，开始和 Google 一同开发 Kubernetes。 现在 Kubernetes 是 GitHub 上最大的社区项目之一。

Kubernetes

Kubernetes 原先被设计成使用 Google 的 lmctfy 容器运行时环境来完成工作。在 2014 年夏天，lmctfy 兼容了 docker。Kubernetes 还会在 kubernetes 集群的每个节点运行一个 kubelet 守护进程，这意味着原先使用 docker 1.8 的 kubernetes 工作流看起来是这样的：

kubelet → dockerdaemon @ PID1

回退到了双守护进程的模式。

然而更糟糕的是，每次 docker 的新版本发布都使得 kubernetes 无法工作。Docker 1.10 切换镜像底层存储方案导致所有镜像重建。而 Docker 1.11 开始使用 runc 来启动镜像：

kubelet → dockerdaemon @ runc @PID1

Docker 1.12 则增加了一个容器守护进程用于启动容器。其主要目的是为了支持 Docker Swarm （Kubernetes 的竞争者之一）：

kubelet → dockerdaemon → containerd @runc @ pid1

如上所述，每一次 docker 发布都破坏了 Kubernetes 的功能，这也是为什么 Kubernetes 和 OpenShift 请求我们为他们提供老版本 Docker 的原因。

现在我们有了一个三守护进程的系统，只要任何一个出现问题，整个系统都将崩溃。

走向容器标准化

CoreOS、rkt 和其它替代运行时

因为 docker 运行时带来的问题，几个组织都在寻求一个替代的运行时。CoreOS 就是其中之一。他们提供了一个 docker 容器运行时的替代品，叫 rkt （rocket）。他们同时还引入一个标准容器规范，称作 appc （App Container）。从根本上讲，他们是希望能使得所有人都使用一个标准规范来管理容器镜像中的应用。

这一行为为标准化工作树立了一面旗帜。当我第一次开始和上游 docker 合作时，我最大的担忧就是最终我们会分裂出多个标准。我不希望类似 RPM 和 DEB 之间的战争影响接下来 20 年的 Linux 软件部署。appc 的一个成果是它说服了上游 docker 与开源社区合作创建了一个称作 开放容器计划 （ Open Container Initiative ） (OCI) 的标准团体。

OCI 已经着手制定两个规范：

OCI 运行时规范：OCI 运行时规范“旨在规范容器的配置、执行环境以及生命周期”。它定义了容器的磁盘存储，描述容器内运行的应用的 JSON 文件，容器的生成和执行方式。上游 docker 贡献了 libcontainer 并构建了 runc 作为 OCI 运行时规范的默认实现。

OCI 镜像文件格式规范：镜像文件格式规范主要基于上游 docker 所使用的镜像格式，定义了容器仓库中实际存储的容器镜像格式。该规范使得应用开发者能为应用使用单一的标准化格式。一些 appc 中描述的概念被加入到 OCI 镜像格式规范中得以保留。这两份规范 1.0 版本的发布已经临近（LCTT 译注：已经发布）。上游 docker 已经同意在 OCI 镜像规范定案后支持该规范。Rkt 现在既支持运行 OCI 镜像也支持传统的上游 docker 镜像。

OCI 通过为工业界提供容器镜像与运行时标准化的环境，帮助在工具与编排领域解放创新的力量。

抽象运行时接口

得益于标准化工作， Kubernetes 编排领域也有所创新。作为 Kubernetes 的一大支持者，CoreOS 提交了一堆补丁，使 Kubernetes 除了 docker 引擎外还能通过 rkt 运行容器并且与容器通讯。Google 和 Kubernetes 上游预见到增加这些补丁和将来可能添加的容器运行时接口将给 Kubernetes 带来的代码复杂度，他们决定实现一个叫作 容器运行时接口 （ Container Runtime Interface ） (CRI) 的 API 协议规范。于是他们将 Kubernetes 由原来的直接调用 docker 引擎改为调用 CRI，这样任何人都可以通过实现服务器端的 CRI 来创建支持 Kubernetes 的容器运行时。Kubernetes 上游还为 CRI 开发者们创建了一个大型测试集以验证他们的运行时对 Kubernetes 的支持情况。开发者们还在努力地移除 Kubernetes 对 docker 引擎的调用并将它们隐藏在一个叫作 docker-shim 的薄抽象层后。

容器工具的创新

伴随 skopeo 而来的容器仓库创新

几年前我们正与 Atomic 项目团队合作构建 atomic CLI。我们希望实现一个功能，在镜像还在镜像仓库时查看它的细节。在那时，查看仓库中的容器镜像相关 JSON 文件的唯一方法是将镜像拉取到本地服务器再通过 docker inspect 来查看 JSON 文件。这些镜像可能会很大，上至几个 GiB。为了允许用户在不拉取镜像的情况下查看镜像细节，我们希望在 docker inspect 接口添加新的 --remote 参数。上游 docker 拒绝了我们的代码拉取请求（PR），告知我们他们不希望将 Docker CLI 复杂化，我们可以构建我们自己的工具去实现相同的功能。

我们的团队在 Antonio Murdaca 的领导下执行这个提议，构建了 skopeo。Antonio 没有止步于拉取镜像相关的 JSON 文件，而是决定实现一个完整的协议，用于在容器仓库与本地主机之间拉取与推送容器镜像。

skopeo 现在被 atomic CLI 大量用于类似检查容器更新的功能以及 atomic 扫描 当中。Atomic 也使用 skopeo 取代上游 docker 守护进程拉取和推送镜像的功能。

Containers/image

我们也曾和 CoreOS 讨论过在 rkt 中使用 skopeo 的可能，然而他们表示不希望运行一个外部的协助程序，但是会考虑使用 skopeo 所使用的代码库。于是我们决定将 skopeo 分离为一个代码库和一个可执行程序，创建了 image 代码库。

containers/images 代码库和 skopeo 被几个其它上游项目和云基础设施工具所使用。Skopeo 和 containers/image 已经支持 docker 和多个存储后端，而且能够在容器仓库之间移动容器镜像，还拥有许多酷炫的特性。skopeo 的一个优点是它不需要任何守护进程的协助来完成任务。Containers/image 代码库的诞生使得类似容器镜像签名等增强功能得以实现。

镜像处理与扫描的创新

我在前文提到 atomic CLI。我们构建这个工具是为了给容器添加不适合 docker CLI 或者我们无法在上游 docker 中实现的特性。我们也希望获得足够灵活性，将其用于开发额外的容器运行时、工具和存储系统。Skopeo 就是一例。

我们想要在 atomic 实现的一个功能是 atomic mount。从根本上讲，我们希望从 Docker 镜像存储（上游 docker 称之为 graph driver）中获取内容，把镜像挂在到某处，以便用工具来查看该镜像。如果你使用上游的 docker，查看镜像内容的唯一方法就是启动该容器。如果其中有不可信的内容，执行容器中的代码来查看它会有潜在危险。通过启动容器查看镜像内容的另一个问题是所需的工具可能没有被包含在容器镜像当中。

大多数容器镜像扫描器遵循以下流程：它们连接到 Docker 的套结字，执行一个 docker save 来创建一个 tar 打包文件，然后在磁盘上分解这个打包文件，最后查看其中的内容。这是一个很慢的过程。

通过 atomic mount，我们希望直接使用 Docker graph driver 挂载镜像。如果 docker 守护进程使用 device mapper，我们将挂载这个设备。如果它使用 overlay，我们会挂载 overlay。这个操作很快而且满足我们的需求。现在你可以执行：

# atomic mount fedora /mnt
# cd /mnt

然后开始探查内容。你完成相应工作后，执行：

# atomic umount /mnt

我们在 atomic scan 中使用了这一特性，实现了一个快速的容器扫描器。

工具协作的问题

其中一个严重的问题是 atomic mount 隐式地执行这些工作。Docker 守护进程不知道有另一个进程在使用这个镜像。这会导致一些问题（例如，如果你先挂载了 Fedora 镜像，然后某个人执行了 docker rmi fedora 命令，docker 守护进程移除镜像时就会产生奇怪的操作失败，同时报告说相应的资源忙碌）。Docker 守护进程可能因此进入一个奇怪的状态。

容器存储系统

为了解决这个问题，我们开始尝试将从上游 docker 守护进程剥离出来的 graph driver 代码拉取到我们的代码库中。Docker 守护进程在内存中为 graph driver 完成所有锁的获取。我们想要将这些锁操作转移到文件系统中，这样我们可以支持多个不同的进程来同时操作容器的存储系统，而不用通过单一的守护进程。

我们创建了 containers/storage 项目，实现了容器运行、构建、存储所需的所有写时拷贝（COW）特性，同时不再需要一个单一进程来控制和监控这个过程（也就是不需要守护进程）。现在 skopeo 以及其它工具和项目可以直接利用镜像的存储系统。其它开源项目也开始使用 containers/storage，在某些时候，我们也会把这些项目合并回上游 docker 项目。

驶向创新

当 Kubernetes 在一个节点上使用 docker 守护进程运行容器时会发生什么？首先，Kubernetes 执行一条类似如下的命令：

kubelet run nginx -image=nginx

这个命令告诉 kubelet 在节点上运行 NGINX 应用程序。kubelet 调用 CRI 请求启动 NGINX 应用程序。在这时，实现了 CRI 规范的容器运行时必须执行以下步骤：

1. 检查本地是否存在名为 nginx 的容器。如果没有，容器运行时会在容器仓库中搜索标准的容器镜像。
2. 如果镜像不存在于本地，从容器仓库下载到本地系统。
3. 使用容器存储系统（通常是写时拷贝存储系统）解析下载的容器镜像并挂载它。
4. 使用标准的容器运行时执行容器。

让我们看看上述过程使用到的特性：

1. OCI 镜像格式规范定义了容器仓库存储的标准镜像格式。
2. Containers/image 代码库实现了从容器仓库拉取镜像到容器主机所需的所有特性。
3. Containers/storage 提供了在写时拷贝的存储系统上探查并处理 OCI 镜像格式的代码库。
4. OCI 运行时规范以及 runc 提供了执行容器的工具（同时也是 docker 守护进程用来运行容器的工具）。

这意味着我们可以利用这些工具来使用容器，而无需一个大型的容器守护进程。

在中等到大规模的基于 DevOps 的持续集成/持续交付环境下，效率、速度和安全性至关重要。只要你的工具遵循 OCI 规范，开发者和执行者就能在持续集成、持续交付到生产环境的自动化中自然地使用最佳的工具。大多数的容器工具被隐藏在容器编排或上层容器平台技术之下。我们预想着有朝一日，运行时和镜像工具的选择会变成容器平台的一个安装选项。

系统（独立）容器

在 Atomic 项目中我们引入了 原子主机 atomic host ，一种新的操作系统构建方式：所有的软件可以被“原子地”升级并且大多数应用以容器的形式运行在操作系统中。这个平台的目的是证明将来所有的软件都能部署在 OCI 镜像格式中并且使用标准协议从容器仓库中拉取，然后安装到系统上。用容器镜像的形式发布软件允许你以不同的速度升级应用程序和操作系统。传统的 RPM/yum/DNF 包分发方式把应用更新锁定在操作系统的生命周期中。

在以容器部署基础设施时多数会遇到一个问题——有时一些应用必须在容器运行时执行之前启动。我们看一个使用 docker 的 Kubernetes 的例子：Kubernetes 为了将 pods 或者容器部署在独立的网络中，要求先建立一个网络。现在默认用于创建网络的守护进程是 flanneld，而它必须在 docker 守护进程之前启动，以支持 docker 网络接口来运行 Kubernetes 的 pods。而且，flanneld 使用 etcd 来存储数据，这个守护进程必须在 flanneld 启动之前运行。

如果你想把 etcd 和 flanneld 部署到容器镜像中，那就陷入了鸡与鸡蛋的困境中。我们需要容器运行时来启动容器化的应用，但这些应用又需要在容器运行时之前启动。我见过几个取巧的方法尝试解决这个问题，但这些方法都不太干净利落。而且 docker 守护进程当前没有合适的方法来配置容器启动的优先级顺序。我见过一些提议，但它们看起来和 SysVInit 所使用的启动服务的方式相似（我们知道它带来的复杂度）。

systemd

用 systemd 替代 SysVInit 的原因之一就是为了处理服务启动的优先级和顺序，我们为什么不充分利用这种技术呢？在 Atomic 项目中我们决定在让它在没有容器运行时的情况下也能启动容器，尤其是在系统启动早期。我们增强了 atomic CLI 的功能，让用户可以安装容器镜像。当你执行 atomic install --system etc，它将利用 skopeo 从外部的容器仓库拉取 etcd 的 OCI 镜像，然后把它分解（扩展）为 OSTree 底层存储。因为 etcd 运行在生产环境中，我们把镜像处理为只读。接着 atomic 命令抓取容器镜像中的 systemd 的 unit 文件模板，用它在磁盘上创建 unit 文件来启动镜像。这个 unit 文件实际上使用 runc 来在主机上启动容器（虽然 runc 不是必需的）。

执行 atomic install --system flanneld 时会进行相似的过程，但是这时 flanneld 的 unit 文件中会指明它依赖 etcd。

在系统引导时，systemd 会保证 etcd 先于 flanneld 运行，并且直到 flanneld 启动完毕后再启动容器运行时。这样我们就能把 docker 守护进程和 Kubernetes 部署到系统容器当中。这也意味着你可以启动一台原子主机或者使用传统的基于 rpm 的操作系统，让整个容器编排工具栈运行在容器中。这是一个强大的特性，因为用户往往希望改动容器主机时不受这些组件影响。而且，它保持了主机的操作系统的占用最小化。

大家甚至讨论把传统的应用程序部署到独立/系统容器或者被编排的容器中。设想一下，可以用 atomic install --system httpd 命令安装一个 Apache 容器，这个容器可以和用 RPM 安装的 httpd 服务以相同的方式启动（systemctl start httpd ，区别是这个容器 httpd 运行在一个容器中）。存储系统可以是本地的，换言之，/var/www 是从宿主机挂载到容器当中的，而容器监听着本地网络的 80 端口。这表明了我们可以在不使用容器守护进程的情况下将传统的负载组件部署到一个容器中。

构建容器镜像

在我看来，在过去 4 年来容器发展方面最让人失落的是缺少容器镜像构建机制上的创新。容器镜像不过是将一些 tar 包文件与 JSON 文件一起打包形成的文件。基础镜像则是一个 rootfs 与一个描述该基础镜像的 JSON 文件。然后当你增加镜像层时，层与层之间的差异会被打包，同时 JSON 文件会做出相应修改。这些镜像层与基础文件一起被打包，共同构成一个容器镜像。

现在几乎所有人都使用 docker build 与 Dockerfile 格式来构建镜像。上游 docker 已经在几年前停止了接受修改或改进 Dockerfile 格式的拉取请求（PR）了。Dockerfile 在容器的演进过程中扮演了重要角色，开发者和管理员/运维人员可以通过简单直接的方式来构建镜像；然而我觉得 Dockerfile 就像一个简陋的 bash 脚本，还带来了一些尚未解决的问题，例如：

• 使用 Dockerfile 创建容器镜像要求运行着 Docker 守护进程。

  • 没有可以独立于 docker 命令的标准工具用于创建 OCI 镜像。
  • 甚至类似 ansible-containers 和 OpenShift S2I (Source2Image) 的工具也在底层使用 docker-engine。

• Dockerfile 中的每一行都会创建一个新的镜像，这有助于创建容器的开发过程，这是因为构建工具能够识别 Dockerfile 中的未改动行，复用已经存在的镜像从而避免了未改动行的重复执行。但这个特性会产生大量的镜像层。

  • 因此，不少人希望构建机制能压制镜像消除这些镜像层。我猜想上游 docker 最后应该接受了一些提交满足了这个需求。

• 要从受保护的站点拉取内容到容器镜像，你往往需要某种密钥。比如你为了添加 RHEL 的内容到镜像中，就需要访问 RHEL 的证书和订阅。

  • 这些密钥最终会被以层的方式保存在镜像中。开发者要费很大工夫去移除它们。
  • 为了允许在 docker 构建过程中挂载数据卷，我们在我们维护的 projectatomic/docker 中加入了 -v volume 选项，但是这些修改没有被上游 docker 接受。
• 构建过程的中间产物最终会保留在容器镜像中，所以尽管 Dockerfile 易于学习，当你想要了解你要构建的镜像时甚至可以在笔记本上构建容器，但它在大规模企业环境下还不够高效。然而在自动化容器平台下，你应该不会关心用于构建 OCI 镜像的方式是否高效。

Buildah 起航

在 DevConf.cz 2017，我让我们团队的 Nalin Dahyabhai 考虑构建被我称为 containers-coreutils 的工具，它基本上就是基于 containers/storage 和 containers/image 库构建的一系列可以使用类似 Dockerfile 语法的命令行工具。Nalin 为了取笑我的波士顿口音，决定把它叫做 buildah。我们只需要少量的 buildah 原语就可以构建一个容器镜像：

• 最小化 OS 镜像、消除不必要的工具是主要的安全原则之一。因为黑客在攻击应用时需要一些工具，如果类似 gcc，make，dnf 这样的工具根本不存在，就能阻碍攻击者的行动。
• 减小容器的体积总是有益的，因为这些镜像会通过互联网拉取与推送。
• 使用 Docker 进行构建的基本原理是在容器构建的根目录下利用命令安装或编译软件。
• 执行 run 命令要求所有的可执行文件都包含在容器镜像内。只是在容器镜像中使用 dnf 就需要完整的 Python 栈，即使在应用中从未使用到 Python。

• ctr=$(buildah from fedora):

  • 使用 containers/image 从容器仓库拉取 Fedora 镜像。
  • 返回一个容器 ID （ctr）。

• mnt=$(buildah mount $ctr):

  • 挂载新建的容器镜像（$ctr）.
  • 返回挂载点路径。
  • 现在你可以使用挂载点来写入内容。

• dnf install httpd –installroot=$mnt:

  • 你可以使用主机上的命令把内容重定向到容器中，这样你可以把密钥保留在主机而不导入到容器内，同时构建所用的工具也仅仅存在于主机上。
  • 容器内不需要包含 dnf 或者 Python 栈，除非你的应用用到它们。

• cp foobar $mnt/dir:

  • 你可以使用任何 bash 中可用的命令来构造镜像。

• buildah commit $ctr:

  • 你可以随时创建一个镜像层，镜像的分层由用户而不是工具来决定。

• buildah config --env container=oci --entrypoint /usr/bin/httpd $ctr:

  • Buildah 支持所有 Dockerfile 的命令。

• buildah run $ctr dnf -y install httpd:

  • Buildah 支持 run 命令，但它是在一个锁定的容器内利用 runc 执行命令，而不依赖容器运行时守护进程。

• buildah build-using-dockerfile -f Dockerfile .：

  • 我们希望将移植类似 ansible-containers 和 OpenShift S2I 这样的工具，改用 buildah 以去除对容器运行时守护进程的依赖。
  • 使用与生产环境相同的容器运行时构建容器镜像会遇到另一个大问题。为了保证安全性，我们需要把权限限制到支持容器构建与运行所需的最小权限。构建容器比起运行容器往往需要更多额外的权限。举个例子，我们默认允许 mknod 权限，这会允许进程创建设备节点。有些包的安装会尝试创建设备节点，然而在生产环境中的应用几乎都不会这么做。如果默认移除生产环境中容器的 mknod 特权会让系统更为安全。
  • 另一个例子是，容器镜像默认是可读写的，因为安装过程意味着向 /usr 存入软件包。然而在生产环境中，我强烈建议把所有容器设为只读模式，仅仅允许它们写入 tmpfs 或者是挂载了数据卷的目录。通过分离容器的构建与运行环境，我们可以更改这些默认设置，提供一个更为安全的环境。
  • 当然，buildah 可以使用 Dockerfile 构建容器镜像。

CRI-O ：一个 Kubernetes 的运行时抽象

Kubernetes 添加了 容器运行时接口 Container Runtime Interface （CRI）接口，使 pod 可以在任何运行时上工作。虽然我不是很喜欢在我的系统上运行太多的守护进程，然而我们还是加了一个。我的团队在 Mrunal Patel 的领导下于 2016 年后期开始构建 [CRI-O] 守护进程。这是一个用来运行 OCI 应用程序的 OCI 守护进程。理论上，将来我们能够把 CRI-O 的代码直接并入 kubelet 中从而消除这个多余的守护进程。

不像其它容器运行时，CRI-O 的唯一目的就只是为了满足 Kubernetes 的需求。记得前文描述的 Kubernetes 运行容器的条件。

Kubernetes 传递消息给 kubelet 告知其运行 NGINX 服务器：

1. kubelet 唤醒 CRI-O 并告知它运行 NGINX。
2. CRI-O 回应 CRI 请求。
3. CRI-O 在容器仓库查找 OCI 镜像。
4. CRI-O 使用 containers/image 从仓库拉取镜像到主机。
5. CRI-O 使用 containers/storage 解压镜像到本地磁盘。
6. CRI-O 按照 OCI 运行时规范（通常使用 runc）启动容器。如前文所述，Docker 守护进程也同样使用 runc 启动它的容器。
7. 按照需要，kubelet 也可以使用替代的运行时启动容器，例如 Clear Containers runcv。

CRI-O 旨在成为稳定的 Kubernetes 运行平台。只有通过完整的 Kubernetes 测试集后，新版本的 CRI-O 才会被推出。所有提交到 https://github.com/Kubernetes-incubator/cri-o 的拉取请求都会运行完整的 Kubernetes 测试集。没有通过测试集的拉取请求都不会被接受。CRI-O 是完全开放的，我们已经收到了来自 Intel、SUSE、IBM、Google、Hyper.sh 等公司的代码贡献。即使不是红帽想要的特性，只要通过一定数量维护者的同意，提交给 CRI-O 的补丁就会被接受。

小结

我希望这份深入的介绍能够帮助你理解 Linux 容器的演化过程。Linux 容器曾经陷入一种各自为营的困境，Docker 建立起了镜像创建的事实标准，简化了容器的使用工具。OCI 则意味着业界在核心镜像格式与运行时方面的合作，这促进了工具在自动化效率、安全性、高可扩展性、易用性方面的创新。容器使我们能够以一种新奇的方式部署软件——无论是运行于主机上的传统应用还是部署在云端的微服务。而在许多方面，这一切还仅仅是个开始。

作者简介：

Daniel J Walsh - Daniel 有将近 30 年的计算机安全领域工作经验。他在 2001 年 8 月加入 Red Hat。

via: https://opensource.com/article/17/7/how-linux-containers-evolved

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

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

今年是我们一起庆祝 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中国 荣誉推出

Paul Simon 概括了“与爱人分手的 50 法”，而这里，我们提供了提高系统安全性的 50 种方法。

当我还是小孩子，耳畔萦绕着 Paul Simon 的流行歌“与爱人分手的 50 法”。当我渐渐地长大，突然受歌的启发，收集了 50 种方法，免得你——门内汉和门外汉——遭受黑客侵袭啊：

“你刚刚从后头溜出去了，杰克”

1、 备份你的数据。如果你不幸被勒索软件光顾，那么你就不用支付赎金，因为你做了备份。

2、 当你需要在公共场所为你的手机充电，那就使用 sysncstop吧，或者你也可以用你的备份电池。（LCTT 译注：sysncstop 是一种可以在公共场所安全充电的 USB 设备。在公共场所充电的风险，你知道的。）

3、 利用好你的审计系统，里头有好多很酷的工具可以帮助你监控系统。如果你确实遭到了入侵，那么审计系统也许就可以告诉你发生了什么，以及攻击者做了些什么。

4、 说到日志，把日志定向到集中式服务器上总是一个不错的想法，因为如果某个黑客侵入你的系统里，他首先要攻击的就是日志系统以便隐藏他的踪迹。构建一个好的入侵检测系统来监控日志，这对于防范黑客也很有帮助。

“做份新的计划吧，斯坦”

5、 以强制模式运行 SELinux（见 StopDisablingSelinux.com）。不要觉得我现在还在喋喋不休地说这个可笑。SELinux 可以防止 0day 漏洞的影响。当破壳漏洞出现的时候，SELinux 曾是唯一的防护手段。

6、 如果可能，在 SELinux 沙盒中运行应用程序吧——在容器火遍全球前，它就已经是容器了。同时，请关注 Flatpack 开发，这个工具很快会开发沙盒功能。

7、 不要安装或者使用 Flash。Firefox 不再支持它了，同时也希望大多数 web 服务器正在远离它。

8、 使用受约束的 SELinux 用户来控制用户在你的系统中所能做的事。如果你正运行着一台共享登录的系统，设置用户为 guest_t。

“你不必害羞，罗伊”

9、 利用 systemd 工具的能力来帮助你提升系统安全。大多数系统攻击是通过那些监听着网络的服务来实现的，而 Systemd 提供了一些很棒的方法来锁定服务。例如，使用 PrivateTmp=yes 。Privatemp 利用挂载命名空间来为服务器的 /tmp 设置一个私有的 tmpfs 挂载，这可以阻止被入侵的服务访问到主机 /tmp 中的内容，以及针对系统中基于监听 /tmp 的服务的潜在攻击。

10、 InaccessibleDirectories=/home 是一个 systemd 单元的选项，它使用挂载命名空间的方式使从服务的角度看不到 /home 目录（或者其它任何目录），这会使得被入侵的服务攻击到数据更为困难。

11、 ReadOnlyDirectories=/var 是另外一个 systemd 单元的选项，它使用挂载命名空间的方式来将目录内容变成只读模式。基本上你总是可以让 /usr 运行在只读模式。这可以阻止一个被入侵的应用程序重写二进制文件，因为那可以在下次服务重启时，该服务依旧是被入侵的。

12、 降低服务权限（CapabilityBoundingSet=CAP_CHOWN CAP_KILL）。在内核中，特权服务被分解成一些列不同的权限。大多数服务不需要很多权限（如果需要一些的话），而 systemd 提供了一个简单的开关来从服务中剥离这些权限。

13、 如果服务不使用网络，那么你可以使用 PrivateNetwork=yes 来为该服务关闭网络功能。只需在服务的单元文件中开启该选项，就可以享受它带来的好处，关闭服务所有可用的网络。黑客常常并不是真的想破坏你的机器——他只是想用它作为攻击服务器来攻击其它机器。如果服务连不上网络，那么就不会受到攻击。

14、 控制服务可用的设备。 Systemd 提供了 DeviceAllow 配置，它控制了该服务可用的设备。DeviceAllow=/dev/null rw 将访问限制为 /dev/null，且仅可访问该设备节点，不允许对其它任何设备节点的访问。该功能实现于设备的 cgroup 控制器顶端。

15、 Systemd 系统即将迎来的一个新功能是 ProtectSystem Strict，该功能可以开启所有这些命名空间以完全锁定服务运行的环境。

“刚刚重获自由”

16、 不要使用没有运行着 SELinux（SEAndroid）强制模式的手机。幸运的是，我听说目前超过 90% 的安卓手机都运行着 SEAndroid 的强制模式，这真让我高兴。现在要是我们能让那些果粉们使用 SELinux 就好了。

17、 只从受信源安装软件。不要安装你从因特网找来的危险东西，对于你的手机、计算机系统、虚拟机以及容器等等也一样。

18、 我不会在我的手机上进行网上银行操作——我只在我的 Linux 计算机上做这事儿。如果黑客偷了我的信用卡，也许我就丢了那么 50 美元；而如果他黑进我的银行账户，那我丢的钱就会更多。我想我是个老古板。（“滚出我的地盘。”——那些老古板都会这样说。）

19、 我用我手机做的一件很酷的事情，就是设置让我的信用卡公司每次在我的信用卡消费时给我发送短信。那样的话，如果账号被盗，我会更快地知道。

20、 当你需要安全地通讯，请使用 Signal 安全信息应用。

“搭个便车，格斯”

21、 在你的计算机系统上运行 Linux。当我第一次想用计算机联络我的父亲时，在他的计算机中毒前，我很少回家。我回去给他的系统安了个 Linux，而他从那以后就一直运行着它。我相信 Linux 大体上说是一个更加安全的系统，因为它的设计方式。而且我也相信这个桌面被黑的可能性也相对较小，因为用它的人相对较少。有些人或许要持反对意见了，他们会说 Windows 在过去几年中已经有了很大的改进了，但对于我而言，我仍然坚持己见。

22、 只运行那些有安全响应团队进行安全监管的发行版。企业软件及其重要。

23、 运行一个企业级内核。在容器中，单点故障往往是内核。如果你想要保证它安全，那么就使用一个企业级内核，即便它不是一个最新的版本，但也包含了最新的安全补丁。记住，最新的内核虽然带来了最新的安全补丁，但是它也带来了大量的新代码，这些代码可能存在漏洞。

“你不要说太多”

24、 大多数非法入侵都是通过社会工程学实施的——例如，电子邮件链接、web 浏览器攻击，以及电话。对于此，最好的选择是接受相关教育，并且对一切留个心眼儿。没有哪个来自尼日利亚的家伙会给你钱，国税局也不会打电话到你家问你要钱。如果你电子邮件收到了来自你银行的电子邮件，里面包含有到某个网站的链接，那么不要直接去点击那个链接，在 web 浏览器中输入那个地址来打开。

25、 总是把你的系统打上最新的安全补丁。已知有安全漏洞以及过时的系统的数量十分可怕，脚本小子们依赖于你不更新系统。

26、 当连接到网络上的服务时，请始终使用 HTTPS。Chrome 和 Firefox 现在有个强制开启 HTTPS 的模式。到 2016 年为止，那些还不支持安全通讯的网站可能就不值得你们访问。

27、 在你的容器中使用 seccomp，这会将攻击限制在内核之外，内核是个单点故障。限制什么进程可以具体讨论。

“就把那钥匙丢下吧，李”

28、 使用 YubiKey 来存储私钥。

29、 加密你系统上的数据。至少对于笔记本而言，应该把家目录以及你的其它数据目录加密。几年前，我正乘坐在伦敦的地铁上，我的笔记本就成了某些人的目标——我下了车，车门关上了，而我发现我的笔记本不见了。此时，地铁已经驶出了站台。幸运的是，我把磁盘加密了。

30、 给你的所有网站用上 Let's Encrypt 吧，没有任何理由不再运行 HTTPS 了。

31、 绝不要在不同 web 服务器上使用相同的密码。虽然这个很难不落入陷阱，但是像 Let's Encrypt 这样的工具会有很大帮助。如果你使用 ssh 密钥来登录进系统，这会更好。

32、 使用双因素认证（2FA）。密码变得无关紧要，使用 Yubikey 以及诸如此类的工具可以使得双因素认证很方便，我们都有手机。在大脑中记一个密码，并在手机中生成一个密钥，总是比一个密码来得更好。

33、 网站总要我注册个帐号，没有比这更激怒我的事情了——我们就不能做得更好点？对于网站密码，始终都要使用密码生成工具来生成。我是个保守派：我使用 Password Safe 来生成密码，然后剪切粘贴到 web 浏览器中。我听说，其他人使用 LastPass，或者其它整合在手机和 web 服务中的工具也用着不错。

34、 配置像 FreeIPA 之类的服务用于身份认证。使用像 Kerberos 之类的工具来认证和授权，会使得跟踪雇员及其对系统的访问更为简便（而且它也有很酷的加密服务）。使用活动目录也很不错，或许我有点偏颇。

35、 如果你经常输入密码，那就使用一个容易记忆的句子，而不是一个单词。我所偏好的用于记忆密码的方式，就是使用有几个单词并且易于输入的词组。

“让自己自由”

36、 使用 USBGuard 来保护你的系统免遭流氓 USB 设备破坏。

37、 在过去几年中，我一直工作于容器方面，让我们来说说容器的安全吧。首先，让它们在开启强制模式的 SELinux 的系统中运行。如果你的系统不支持 SELinux，那就换个支持它的版本吧。SELinux 是使用文件系统来保护容器免遭破坏的最佳工具。

38、 如果可能，在容器中跑你的服务吧。我相信，使用 OCI 镜像格式 和 Linux 容器技术是应用的未来。用 runC、OCID、RKT、Systemd-nspawn 等等来启动这些容器。虽然我常常说“容器并不包容“，但是不要在容器外面运行这些服务更好一些。

39、 在虚拟机中运行容器。虚拟机提供比容器更好的隔离机制，在虚拟机中跑像容器之类的东西，更加灵活有弹性，并且互相隔离。

40、 在不同的虚拟机中，按不同的安全需求跑容器应用。你可以在 DMZ 中的虚拟机上跑 web 服务容器，而在 DMZ 外的虚拟机上跑数据容器。

41、 同时，记得在不同的物理机上跑需要最高安全性的虚拟机，并且容器放在不同虚拟机上（这也叫深度防护）（LCTT 译注：此处原文有误，根据理解修改）。

42、 以只读模式跑容器。开发环境中的容器需要能够写入到 /usr，但是生产环境中的容器只能写入到 tmpfs，并且将卷挂载到容器中。

43、 降低容器权限。不管是在容器中，还是在容器外，我们都以比它们所需的更多的“权限”跑它们的进程，你可以通过降低权限来让你的进程更加安全。

44、 不要以 root 身份在容器中跑进程。大多数服务都不需要 root 特权，或者它们需要该权限来绑定到低于 1024 的端口，然后切换到非 root 用户。我建议你始终以非 root 身份来跑应用。

45、 给你的容器打上最新的 CVE 补丁。使用像 OpenShift 这样的工具来构建并维护你的容器镜像是个不错的主意，因为它会在新的安全补丁出现时自动重构容器镜像。

46、 我的一个同事说 “Docker 就是用来在你的主机上以 root 身份运行来自因特网的随机代码的。”从一个受信源获取软件，不要抓取你在 docker.io 上随便找到的第一个 Apache 应用。操作系统有重要关系。

47、 在一台受限的容器化优化的主机上跑生产环境容器，例如在一台原子主机上，它开启了所有安全特性，为运行中的容器而优化，带有限制攻击层和原子级更新。有什么不喜欢的吗？

48、 使用像 OpenScap 这样的工具来扫描你系统的漏洞。糟糕的是，新的漏洞总是层出不穷，所以你得时刻更新你的扫描器。（也可以看看 原子扫描，用于扫描你的容器。）

49、 OpenScap 也具有扫描安全配置的功能，如 STIG（安全技术部署指南）。

50、 为你孩子收到的所有那些圣诞物联网设备设置一个特别的客户网络。我钟爱我的 Amazon Echo，还有自动化灯以及电源开关（“Alexa，打开圣诞灯“），但是所有这些都是由可能存在安全问题的 Linux 操作系统控制。

“一定还有着另外 50 种免遭黑客侵害的方法”

你会为这个列表添加点什么呢？在下面的评论中告诉我们吧。

Josh Bressers 对本文作出贡献。

作者简介：

Daniel J Walsh - Daniel Walsh 已经致力于计算机安全领域将近 30 年。Dan 在 2001 年 8 月份加入 Red Hat。

via: https://opensource.com/article/17/1/yearbook-50-ways-avoid-getting-hacked

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

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