为什么 CAP_CHROOT 等同于 root？

Question

我无法理解CAP_CHROOT给定以下模板的根等价。

我理解 1) 意味着创建一个目录结构，包含所有依赖项（例如共享对象），其根将是chroot(2).

我的问题涉及模板中的后面步骤：

• 为什么需要后门ld.so或libc在 2) 中？

• 为什么需要在 3) 中从 chroot 环境创建到 setuid-root 二进制文件的硬链接？

• 为什么chroot(2)在 4) 中调用启动 setuid-root 二进制文件？

Answer 1

这不是必需的，这是一种方法。

通过更改根目录，您使系统组件可以做出的假设无效。

/bin/su假设用户数据库位于/etc/passwd/ 中/etc/shadow，libc（或它链接到的任何库）位于某个固定位置/lib，普通用户无法修改。

如果您能够创建不同的文件系统布局，其中/bin/su可以运行相同的命令，但可以随意修改不同的/etc/passwd或不同的命令libc，那么您可以做任何事情（作为su使用或可以使用（可能间接）/etc/passwd来验证用户，并在 libc 中运行代码）。

现在，通过这种方法，拥有CAP_CHROOT并不是你唯一需要的东西。您还需要对至少具有一个动态链接的 setuid-root 可执行文件的文件系统上的目录进行写访问（因为硬链接只能在给定的文件系统内完成）。

系统分区没有用户可写区域（甚至是只读）的系统并不少见。将带有用户可写区域的文件系统挂载一个nosuid标志也是很常见的。许多系统还禁止硬链接您不拥有的文件（例如，请参阅fs.protected_hardlinksLinux 3.6+ 上的sysctl）。

但是您不需要在 chroot jail 中硬链接 setuid 可执行文件。你也可以这样做：

chdir("/");
chroot("/tmp/myjail");
execl("bin/su", "su", 0);

因为即使进程的根被改变chroot，当前工作目录将仍然可用后，即使该/目录和bin/su从那里不解决内部的监狱。并且/bin/su仍然会在您的 jail 中查找ld.so,/etc/passwd或 libc，因为它们是通过绝对路径访问的，因此相对于更改的根目录。让当前工作目录或任何文件描述符在监狱外的文件上打开，可以让您走出监狱。