从安全视角来看 LXD 容器管理程序

上个月在 Linux 安全峰会上的演讲，介绍了LXD 在容器安全方便存在的问题。LXD 是Canonical 基于Linux 容器（LXC）开发的容器管理程序。 Stéphane Graber 和 Tycho Andersen 的议题讨论了一些问题的细节。

LXD 不是一种新的虚拟化技术，而是一个利用 LXC 特性的工具。LXC 使用由内核提供的名字空间（namespace）和控制组（control groups, cgroups）特性来实现。因此，它使用名字空间API 提供的安全功能。

LXD 中广泛使用了 cgroups 来实施资源配额，对容器的 CPU、内存交换、磁盘和网络流量进行限制。这也使得任何因为共享内核资源引起的问题，会影响到所有运行中的容器。其中一个示例是用于追踪文件系统变动的 inotify 句柄。该资源的全局限制是每个用户 512 个，这意味着主机上所有运行的容器最多能使用 512 个句柄。这对于像 systemd 这样的应用程序来说是远远不够的。当 systemd 因为 inotify 句柄不足退而使用轮训文件系统时，对系统影响会更大。其他类似的资源还包括网络表（例如用于保存路由项）和 ulimit。

对于上述问题中的一部分，建议的解决方案是虚拟化存在限制的环境，例如将限制绑定到名字空间，使其成为容器的局部属性。然而，对于类似 ulimit 这样的属性，目前还不完全清楚哪个名字空间比较适合。

LXD 以 root 特权的守护进程运行，这意味它比 LXC 拥有更多的特权。LXD 确实从其容器中移除了一些功能，例如加载 / 卸载内核模块，但是保留了大部分功能，因为它无法提前预知容器中运行的应用程序需要哪些功能。

Linux 安全模块（Linux Security Modules, LSM）是一个 Linux 框架，它允许插入一个安全模块的实现，在不依赖特定模型的情况下来执行访问控制。LSM 的实现有 AppArmor 和 SELinux。LXC 同时支持 AppArmor 和 SELinux，而 LXD 目前只支持 AppArmor。LXD 容器的首选隔离方案是名字空间，但是也安装了一个 AppArmor 配置文件以避免跨容器访问资源（例如文件）。

演讲的第二部分覆盖了容器的检查点和恢复功能。检查点和恢复进程保存运行中的容器内存状态，并允许在将来的某个时间点恢复回来。检查点 / 恢复功能的技术涉及到通过类似 ptrace 系统调用来深入获取进程的状态。然而，类似 seccomp 这样的安全措施可能会阻止类似的系统调用，因此检查点功能需要特别的处理。

查看英文原文： Security Insights into the LXD Container Hypervisor