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