剑客
关注科技互联网

从安全视角来看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

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址