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

  • Hrishikesh Barua
  • 金灵杰

2016 年 10 月 24 日

话题:LinuxDevOps运维

上个月在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

LinuxDevOps运维