我一直在学习 Linux 中的 MAC（强制访问控制）系统。通常，但并非总是如此，这些都与Linux 安全模块相关联。我看过的一些系统：SELinux、Tomoyo、AppArmor、grsecurity、Smack。
据我了解，所有这些系统都依赖于设置规则目录。这些规则为文件和系统资源定义了更细粒度的访问策略，从而提高了安全性。
考虑到限制对文件的访问的意图，我们必须知道“哪些”文件是合乎逻辑的，因此文件引用对于这些规则有意义是必不可少的。这与我的问题有关。
除了 SELinux 和 Smack 的明显例外，其他方法使用文件路径（路径名）来识别规则中的文件。我看到其他人认为这种方法不安全，因为一个文件可能同时有多个名称（链接、绑定安装等）。
使用路径名的方法安全吗？这些基于路径名的方案的优缺点是什么？说“基于路径名的 MAC（例如 TOMOYO、grsecurity、AppArmor ……）存在真正的概念缺陷”是否准确？
这种方法经常被认为是不安全的，即一个文件可能同时有多个名称（链接、绑定挂载等）。
一个文件可以有多个安全上下文，每个名称一个。但是，这是否不安全取决于您如何看待它：
/usr/bin也不应该是可写的。理论上！然而，除此之外，MAC 类型项目的目标是限制进程和用户，以便以用户身份运行的进程仅以它需要的必要权限运行。很少有应用程序（可能除外ln）需要创建符号链接的能力，而那些不需要在所有目录和路径上创建符号链接的应用程序。因此，应该可以为大多数流程实施所需的遏制。
虽然不受路径名中潜在问题的影响，但基于 inode 的安全性确实存在问题：
vim。我认为差异非常微妙，并不是一个比另一个更安全，因为每个都有其优点和缺点。正确理解，两者都可以实施安全策略。
Grsecurity 不是像 TOMOYO 或 AppArmor 那样纯粹的基于路径名的 MAC 系统。策略是使用路径名描述的（与所有其他系统相同，包括 SELinux），但这些在启用时转换为 inode/dev 对并在此后使用。路径名仅在匹配来自策略的正则表达式或提供“策略重新创建”时使用——考虑到 SELinux 将 vim 修改的文件恢复为默认安全上下文（一个严重的问题！）的其他评论中的情况，grsecurity 将检测这种情况并将该对象上的先前策略应用于新策略。
有趣的是，在将 grsecurity 与纯基于路径名的 MAC 系统混为一谈并传播 FUD 的同时，SELinux 本身最近在最近的版本中添加了对文件名信息的使用，以完全实现 grsecurity 从第一天开始就一直在做的事情。
叔本华所说的似乎是真的：“所有的真理都经过三个阶段。第一，它被嘲笑。第二，它被强烈反对。第三，它被认为是不言而喻的。”
我在我的 grsecurity RBAC 教程演示文稿中讨论了有关此主题的更多详细信息：https ://grsecurity.net/rbac_tutorial.pdf
-布拉德
我认为，一般来说，基于路径名的访问控制在概念上根本没有缺陷，它甚至可能有优势，但目前的实现并不方便。
优点是您可以在一个地方指定更清晰、更易于理解的策略，并且不会遇到 xattrs 遍布整个文件系统的复杂情况。我说，可思考性很重要。缺点是某些实现无法以易于用户的方式处理硬链接或重命名。
TOMOYO作者有答案：http ://tomoyo.sourceforge.jp/wiki-e/?WhatIs#g6a56098基本上，他们说您可以禁止链接/重命名重要文件，并且默认情况下禁止链接/重命名，所以“没问题”。我不同意，所有这一切都使政策创建和维护变得复杂。不过，这取决于你有什么目标。