【翻译】 大珠子和 LSM 应用程序接口

LWN 订阅者的好处 订阅《LWN》的主要好处是帮助我们继续出版，除此之外，订阅者还可以立即访问网站的所有内容，并使用网站的一些额外功能。 请立即注册！

2006 年 10 月 25 日

本文由 Jake Edge 投稿。

最近，《询问者报》上的一篇评论引起了 LWN 文章的热烈讨论。 这篇评论本身考虑不周，但确实提出了一些关于安全模块、内核和 Linux 安全模块 (LSM) API 的有趣问题。 Dazuko是在 Linux 上运行的少数安全解决方案之一，但这些解决方案并不在内核树中维护，事实上，它们对将其代码移入内核树的建议持相对敌视的态度。

Dazuko 本身是用户空间应用程序处理文件访问控制的一种方法；它的主要用途似乎是在文件级别检查恶意软件，类似于 Windows 反病毒程序的工作方式。 有人会说这是一个不必要的工具，或者说它的实施效果很差，但鉴于似乎有用户需要这种功能，在 Linux 中添加这种功能似乎并不是不合理的。 这似乎正是 LSM 的设计初衷，但 Dazuko 开发人员却有不同的看法。

Dazuko 一开始使用 LSM 钩子来实现他们的应用，但他们发现 LSM 是一个不断变化的目标，每次内核发布都会改变 API。 此外，当加载其他使用 LSM 的模块（最明显的是 SELinux 或 AppArmor）时（各种发行版默认加载这些模块），Dazuko 不再能正常运行。 这导致 Dazuko 开发人员走向了一个内核开发人员显然不会接受的方向：系统调用挂钩。 这种技术拦截系统调用（打开、读取、写入等），并在调用实际内核函数前运行 Dazuko 代码。

这可以看做是开发团队与内核社区之间常见的阻抗失配之一，但在本例中却比这更深一层。 Dazuko 特别提到，基于规则集的访问控制（RSBAC）是一个内核安全框架，它可以与之轻松对接。 RSBAC 是一套内核补丁，实现了比 LSM 提供的更全面的访问控制钩子。 该项目用相当长的篇幅说明了不使用 LSM 的理由，并指出另一个项目grsecurity也存在类似的 LSM 问题。

关于将 LSM 从内核中移除的讨论一直在进行，SELinux 人员对此也非常支持。 在今年的内核峰会（LWN在此进行了报道）之前，人们普遍认为这会发生。 似乎很少有人对 LSM 特别着迷。 它是 SELinux 被内核接受时的一种妥协，目的是允许其他安全框架替代。 在大多数情况下，至少在主线内核中，它并没有做到这一点。

在这种情况下，人们希望内核能有一个新的应用程序接口来更新和增强 LSM，以便将更多的替代框架纳入内核。 其中一个障碍可能是人们认为 Linus 和内核开发人员拒绝接受任何对性能有明显影响的安全钩子。 虽然我们完全可以理解，因为只有少数人使用的钩子而惩罚所有内核用户的做法是不可接受的，但这确实给那些希望使用更具侵入性钩子的人带来了难以逾越的障碍。

Dazuko 一直在开发一种可堆叠文件系统，它可以通过在常规内核文件系统 "顶部 "挂载 DazukoFS 来提供相同类型的服务。 这将允许 Dazuko 使用已获批准的内核接口工作，并为将来将其移入内核树提供了可能性。 另一个替代方案是使用用户空间文件系统（FUSE）接口来提供该功能，但 FUSE 是否能解决整个问题尚不清楚。 对于需要更多侵入钩子的安全框架来说，除了树外开发，没有真正的替代方案。 因此，RSBAC 和 grsecurity 可能会在每一个新内核发布时继续将其补丁移植到新内核中。 这些获得 GPL 授权的替代安全机制不可能进入内核树，这似乎很不幸，但它们似乎陷入了众所周知的困境。

本文索引条目
特邀文章	边缘, 杰克

---

(登录后发表评论）