AppArmor：如何使用CAP_SYS_ADMIN / CAP_SYS_CHROOT阻止pid = host容器读取某些主机文件？

问题描述

给定是一个具有pid=host的容器（因此它位于初始PID名称空间中，并且对所有进程均具有完整视图）。此容器（而是其过程）还具有CAP_SYS_ADMIN和CAP_SYS_CHROOT功能，因此它可以使用setns(2)更改装载名称空间。

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

解决方法

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

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

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

但是阻止对某些主机文件访问路径的访问总是伴随着在容器内（不同的挂载命名空间）阻止相同访问路径完全有效使用的危险，因此这需要非常小心，进行大量研究和测试，因为以及在容器的下一次更新中出现问题的持续危险。 AppArmor seems to not be designed for such usecases。