安全命名空间：使Linux安全框架可用于容器

作者： {Zebork}@ArkTeam

原文作者： Yuqiong Sun, Symantec Research Labs; David Safford, GE Global Research; Mimi Zohar, Dimitrios Pendarakis, and Zhongshu Gu, IBM Research; Trent Jaeger, Pennsylvania State University

原文标题： Security Namespace: Making Linux Security Frameworks Available to Containers

原文会议： 2018 USENIX Security Symposium

原文链接： https://www.usenix.org/conference/usenixsecurity18/presentation/sun

Linux 容器的共享内核会阻止容器利用传统 VM 和主机可用的安全功能，容器无法应用本地策略来管理完整性测量，代码执行，强制访问控制等。在本文中，我们提出了安全命名空间，这是一种内核抽象，使容器能够对其安全性进行自主控制。我们通过在 Linux 内核中开发用于完整性测量和强制访问控制的命名空间来演示安全命名空间，以供 Docker 容器使用。结果表明，安全命名空间可以有效地缓解容器内的安全问题（例如，恶意代码执行），系统调用的额外延迟小于 0.7 ％，应用程序吞吐量几乎相同。因此，安全命名空间使容器能够获得对其安全性的自主控制，而不会损害其他容器或主机系统的安全性。

一、设计目标

本文的终极目标是研究安全命名空间的设计，使容器具有自主安全控制。 但是，这样做不应损害系统的安全性。 由于内核安全框架的多样性及其不同的设计视角和细节，设计很难通用。 但我们试图通过研究两个常用的内核安全框架（即 IMA 和 AppArmor ）来抽象共性，并希望它可以为其他内核安全框架提供有用的指导，并最终导致通用设计。

二、整体框架

一个进程的操作，被路由到可能对该操作有意见的安全命名空间。
每个涉及的安全命名空间，独立地做出安全决策，并且如果所有涉及的安全命名空间允许该操作，则允许该操作。

图1 总体框架图

三、性能

图2 对比安全命名空间对系统造成的性能影响

安全命名空间在一个命名空间场景（容器云的最典型场景）中引入了大约 0.7 ％的开销，并且即使存在 10 个安全命名空间，也会产生最多 3.5 ％的开销。

四、讨论

本文旨在尝试在 Linux 底层对容器的安全性框架进行设计，以便于在不影响主机安全性的情况下，给予容器更大的安全自主权，虽然其算法比较简单，但是设计思路独特，有借鉴的意义。