☰

为什么CAP_CHROOT相当于root？

tag-icon • tag-icon debian security chroot capabilities
为什么CAP_CHROOT相当于root？

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

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

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

  • 为什么需要后门ld.so或libc2）？

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

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

在此输入图像描述

答案1

它不是必要的，这是一种方法。

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

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

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

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

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

但您不需要在 chroot 监狱内硬链接 setuid 可执行文件。您还可以这样做：

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

因为即使进程的根目录被更改chroot，当前工作目录之后仍然可用，即使该/目录和bin/su从那里解析的目录不可用里面监狱。并且/bin/su仍然会在你的监狱中寻找ld.so,/etc/passwd或 libc 因为它们是通过绝对路径访问的，所以相对于改变根目录。让当前工作目录或任何文件描述符在监狱外的文件上保持打开状态，将为您提供一扇离开监狱的门。

相关内容