0

Given 是一个具有pid=host（因此它位于初始 PID 命名空间中并且对所有进程具有完整视图）的容器。这个容器（更确切地说，它的进程）还具有 和 功能CAP_SYS_ADMIN，CAP_SYS_CHROOT因此它可以使用setns(2).

  • 是否可以使用 AppArmor 阻止此容器访问主机中的任意文件（初始挂载命名空间），但某些文件除外，例如/var/run/foo？
  • AppArmor 如何根据挂载命名空间评估文件系统路径名？它是“忽略”挂载命名空间并只采用指定的路径，还是转换路径，例如在处理绑定挂载的子树等时？
4

1 回答 1

0

AppArmor 架构的一个根深蒂固的限制是，在文件系统资源（文件、目录）的情况下，它使用访问路径来调解访问。AppArmor 与 SELinux 一样使用标签，但 AppArmor仅从访问路径派生隐式文件系统资源标签。相反，SELinux 使用显式标签，这些标签存储在支持 POSIX 扩展属性的文件系统上的文件的扩展属性中。

现在，访问路径始终是调用者当前挂载命名空间中看到的路径。或者，AppArmor 可以考虑 chroot。所以第二个问题的答案是：AppArmor“忽略”挂载命名空间，只采用（访问）路径。据我所知，它不会翻译绑定安装（没有任何迹象表明它会这样做）。

至于第一个问题：一般“否”，由于AppArmor调解访问路径（标签），而不是文件资源标签。当接受容器内的内容与容器外的主机中的内容之间没有任何访问路径差异（其他容器内的内容相同）时，可能会进行有限的访问限制。这基本上是Docker 的默认容器 AppArmor 配置文件所做的：限制对一些高度敏感的 /proc/ 条目的所有访问，并限制对许多其他 /proc/ 条目的只读访问。

但是阻止对某些主机文件访问路径的访问总是伴随着阻止相同访问路径以在容器内完全有效使用的危险（不同的挂载命名空间），因此这需要非常小心，大量的研究和测试，以及在容器的下一次更新中不断有东西破裂的危险。AppArmor 似乎不是为此类用例而设计的。

于 2021-02-25T08:45:05.567 回答