当前位置：文江博客话题详情

从内部检测 chroot 监狱

发布于 2024-07-05 02:04:11 字数 320 浏览 15 评论 0原文

如果没有 root 权限，如何检测是否处于 chroot 监狱中？假设有一个标准的 BSD 或 Linux 系统。我想出的最好办法是查看“/”的 inode 值并考虑它是否相当低，但我想要一种更准确的检测方法。

[edit 20080916 142430 EST] 仅仅查看文件系统是不够的，因为复制 /boot 和 /dev 等内容来欺骗被监禁的用户并不困难。

[edit 20080916 142950 EST] 对于 Linux 系统，检查 /proc 中的意外值是合理的，但是对于首先不支持 /proc 的系统呢？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

瞄了个咪的 2024-07-12 02:04:11

如果 / 是 ext2/ext3/ext4 文件系统的根目录，则 / 的 inode 将始终为 2，但您可能会在完整的文件系统中进行 chroot。如果只是 chroot（而不是其他虚拟化），您可以运行 mount 并将已安装的文件系统与您所看到的进行比较。验证每个挂载点都有 inode 2。

回复收藏 0 原文

调妓 2024-07-12 02:04:11

在具有root权限的Linux上，测试init进程的根目录是否是您的根目录。虽然 /proc/1/root 始终是 / 的符号链接，但跟随它会导致“master”根目录（假设 init 进程没有 chroot，但这是几乎没有做过）。如果 /proc 没有安装，你可以打赌你处于 chroot 状态。

[ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]
# With ash/bash/ksh/zsh
! [ -x /proc/1/root/. ] || [ /proc/1/root/. -ef / ]

这比查看 /proc/1/exe 更精确 因为如果 init 自上次启动以来已经升级，或者 chroot 位于主根文件系统和 init 之外，那么在 chroot 之外可能会有所不同> 是硬链接的。

如果没有root权限，可以查看/proc/1/mountinfo和/proc/$$/mountinfo（简要记录在Linux 内核文档中的 filesystems/proc.txt）。该文件是世界可读的，并且包含有关文件系统进程视图中每个挂载点的大量信息。该文件中的路径受到影响读取器进程（如果有）的 chroot 的限制。如果读取 /proc/1/mountinfo 的进程被 chroot 到与全局根不同的文件系统中（假设 pid 1 的根是全局根），则没有 / 出现在 /proc/1/mountinfo 中。如果读取 /proc/1/mountinfo 的进程被 chroot 到全局根文件系统上的目录，则 / 条目将出现在 /proc/1/ 中mountinfo，但具有不同的挂载 ID。顺便说一句，root 字段 ($4) 指示 chroot 在其主文件系统中的位置。再次强调，这是 Linux 特有的。

[ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$/mountinfo)" ]

On Linux with root permissions, test if the root directory of the init process is your root directory. Although /proc/1/root is always a symbolic link to /, following it leads to the “master” root directory (assuming the init process is not chrooted, but that's hardly ever done). If /proc isn't mounted, you can bet you're in a chroot.

[ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]
# With ash/bash/ksh/zsh
! [ -x /proc/1/root/. ] || [ /proc/1/root/. -ef / ]

This is more precise than looking at /proc/1/exe because that could be different outside a chroot if init has been upgraded since the last boot or if the chroot is on the main root filesystem and init is hard linked in it.

If you do not have root permissions, you can look at /proc/1/mountinfo and /proc/$$/mountinfo (briefly documented in filesystems/proc.txt in the Linux kernel documentation). This file is world-readable and contains a lot of information about each mount point in the process's view of the filesystem. The paths in that file are restricted by the chroot affecting the reader process, if any. If the process reading /proc/1/mountinfo is chrooted into a filesystem that's different from the global root (assuming pid 1's root is the global root), then no entry for / appears in /proc/1/mountinfo. If the process reading /proc/1/mountinfo is chrooted to a directory on the global root filesystem, then an entry for / appears in /proc/1/mountinfo, but with a different mount id. Incidentally, the root field ($4) indicates where the chroot is in its master filesystem. Again, this is specific to Linux.

[ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$/mountinfo)" ]

回复收藏 0 原文

熟人话多 2024-07-12 02:04:11

如果您使用 schroot 输入 chroot，则可以检查 $debian_chroot 的值。

回复收藏 0 原文

烟织青萝梦 2024-07-12 02:04:11

我想要在 FreeBSD 上运行的监狱的相同信息（因为 Ansible 似乎没有检测到这种情况）。

在 FreeBSD 11 的 FreeNAS 发行版上，/proc 未安装在主机上，但它位于监狱内。我不确定在常规 FreeBSD 上是否也是如此，但是 procfs：走了但没有被遗忘似乎表明确实如此。无论哪种方式，您可能都不想尝试安装它只是为了检测监狱状态，因此我不确定它是否可以用作监狱内的可靠预测器。

我还排除了在 / 上使用 stat 的可能性，因为在 FreeNAS 上，所有监狱都拥有自己的文件系统（即 a ZFS 数据集），因此主机上和监狱中的 / 节点都有 inode 4。我预计这在 FreeBSD 上很常见一般为11。

的方法是在 pid 0 上使用 procstat 。

[root@host ~]# procstat 0
  PID  PPID  PGID   SID  TSID THR LOGIN    WCHAN     EMUL          COMM        
    0     0     0     0     0 1234 -        swapin    -             kernel      
[root@host ~]# echo $?
0
[root@host ~]# jexec guest tcsh
root@guest:/ # procstat 0
procstat: sysctl(kern.proc): No such process
procstat: procstat_getprocs()
root@guest:/ # echo $?
1

所以我决定这里假设 pid 0 将始终是主机上的内核，并且监狱内不会有 pid 0。

I wanted the same information for a jail running on FreeBSD (as Ansible doesn't seem to detect this scenario).

On the FreeNAS distribution of FreeBSD 11, /proc is not mounted on the host, but it is within the jail. Whether this is also true on regular FreeBSD I don't know for sure, but procfs: Gone But Not Forgotten seems to suggest it is. Either way, you probably wouldn't want to try mounting it just to detect jail status and therefore I'm not certain it can be used as a reliable predictor of being within a jail.

I also ruled out using stat on / as certainly on FreeNAS all jails are given their own file system (i.e. a ZFS dataset) and therefore the / node on the host and in the jail both have inode 4. I expect this is common on FreeBSD 11 in general.

So the approach I settled on was using procstat on pid 0.

[root@host ~]# procstat 0
  PID  PPID  PGID   SID  TSID THR LOGIN    WCHAN     EMUL          COMM        
    0     0     0     0     0 1234 -        swapin    -             kernel      
[root@host ~]# echo $?
0
[root@host ~]# jexec guest tcsh
root@guest:/ # procstat 0
procstat: sysctl(kern.proc): No such process
procstat: procstat_getprocs()
root@guest:/ # echo $?
1

I am making an assumption here that pid 0 will always be the kernel on the host, and there won't be a pid 0 inside the jail.

回复收藏 0 原文

萌逼全场 2024-07-12 02:04:11

在 BSD 系统上（使用 uname -a 检查），proc 应始终存在。检查 /proc/1/exe 的 dev/inode 对（在该路径上使用 stat，它不会通过文本跟踪符号链接，而是通过底层挂钩）匹配 /sbin/init。

检查根目录中的 inode #2 也是一个不错的选择。

在大多数其他系统上，root 用户可以通过尝试 fchdir root 破解技巧来更快地找到答案。如果它跑到任何地方，你就会被关进 chroot 监狱。

回复收藏 0 原文

冷默言语 2024-07-12 02:04:11

我想这取决于你为什么会处于 chroot 状态，以及是否付出了任何努力来掩盖它。

我会检查/proc，这些文件是自动生成的系统信息文件。内核会将它们填充到根文件系统中，但它们可能不存在于 chroot 文件系统中。

如果根文件系统的 /proc 已绑定到 chroot 中的 /proc，则该信息与 chroot 环境之间可能存在一些差异。例如检查 /proc/mounts。

同样，检查/sys。

回复收藏 0 原文

贩梦商人 2024-07-12 02:04:11

防止这样的事情才是重点。如果您的代码应该在 chroot 中运行，请让它在启动时设置一个标志。如果您要进行黑客攻击，请进行黑客攻击：检查已知位置中的几个常见内容，计算 /etc 中的文件数，以及 /dev 中的文件数。

回复收藏 0 原文

幸福还没到 2024-07-12 02:04:11

如果您不在 chroot 中并且根文件系统是 ext2/ext3/ext4，则 / 的 inode 将始终为 2。您可以使用

stat -c %i /

或

ls -id /

Interresting 进行检查，但让我们尝试查找 chroot 目录的路径。询问 stat / 位于哪个设备上：

stat -c %04D /

第一个字节是设备的主要字节，否则字节是次要字节。例如，0802，表示主设备 8，次设备 1。如果您查看 /dev，您将看到该设备是 /dev/sda2。如果您是 root，您可以直接在 chroot 中创建相应的设备：

mknode /tmp/root_dev b 8 1

现在，让我们找到与 chroot 关联的 inode。 debugfs 允许使用 inode 编号列出文件内容。例如，ls -id / 返回 923960：

sudo debugfs /tmp/root_dev -R 'ls <923960>'
 923960  (12) .       915821  (32) ..     5636100  (12) var   
5636319  (12) lib    5636322  (12) usr    5636345  (12) tmp   
5636346  (12) sys    5636347  (12) sbin   5636348  (12) run   
5636349  (12) root   5636350  (12) proc   5636351  (12) mnt   
5636352  (12) home   5636353  (12) dev    5636354  (12) boot   
5636355  (12) bin    5636356  (12) etc    5638152  (16) selinux   
5769366  (12) srv    5769367  (12) opt    5769375  (3832) media

有趣的信息是 .. 条目的索引节点：915821。我可以询问其内容：

sudo debugfs /tmp/root_dev -R 'ls <915821>'
915821  (12) .              2  (12) ..    923960  (20) debian-jail   
923961  (4052) other-jail

目录名为 debian-jail< /code> 有 inode 923960。所以我的 chroot 目录的最后一个组件是 debian-jail。现在让我们看看父目录（inode 2）：

sudo debugfs /tmp/root_dev -R 'ls <2>'
      2  (12) .           2  (12) ..          11  (20) lost+found    1046529  (12) home   
 130817  (12) etc    784897  (16) media     3603  (20) initrd.img   
 261633  (12) var    654081  (12) usr     392449  (12) sys            392450  (12) lib   
 784898  (12) root   915715  (12) sbin   1046530  (12) tmp   
1046531  (12) bin    784899  (12) dev     392451  (12) mnt   
 915716  (12) run        12  (12) proc   1046532  (12) boot               13  (16) lib64   
 784945  (12) srv    915821  (12) opt       3604  (3796) vmlinuz

名为 opt 的目录具有 inode 915821，inode 2 是文件系统的根目录。所以我的 chroot 目录是 /opt/debian-jail。当然，/dev/sda1 可以安装在另一个文件系统上。您需要检查这一点（使用 lsof 或直接选取信息 /proc）。

If you are not in a chroot and the root filesystem is ext2/ext3/ext4, the inode for / will always be 2. You may check that using

stat -c %i /

ls -id /

Interresting, but let's try to find path of chroot directory. Ask to stat on which device / is located:

stat -c %04D /

First byte is major of device and lest byte is minor. For example, 0802, means major 8, minor 1. If you check in /dev, you will see this device is /dev/sda2. If you are root you can directly create correspondong device in your chroot:

mknode /tmp/root_dev b 8 1

Now, let's find inode associated to our chroot. debugfs allows list contents of files using inode numbers. For exemple, ls -id / returned 923960:

sudo debugfs /tmp/root_dev -R 'ls <923960>'
 923960  (12) .       915821  (32) ..     5636100  (12) var   
5636319  (12) lib    5636322  (12) usr    5636345  (12) tmp   
5636346  (12) sys    5636347  (12) sbin   5636348  (12) run   
5636349  (12) root   5636350  (12) proc   5636351  (12) mnt   
5636352  (12) home   5636353  (12) dev    5636354  (12) boot   
5636355  (12) bin    5636356  (12) etc    5638152  (16) selinux   
5769366  (12) srv    5769367  (12) opt    5769375  (3832) media

Interesting information is inode of .. entry: 915821. I can ask its content:

sudo debugfs /tmp/root_dev -R 'ls <915821>'
915821  (12) .              2  (12) ..    923960  (20) debian-jail   
923961  (4052) other-jail

Directory called debian-jail has inode 923960. So last component of my chroot dir is debian-jail. Let's see parent directory (inode 2) now:

sudo debugfs /tmp/root_dev -R 'ls <2>'
      2  (12) .           2  (12) ..          11  (20) lost+found    1046529  (12) home   
 130817  (12) etc    784897  (16) media     3603  (20) initrd.img   
 261633  (12) var    654081  (12) usr     392449  (12) sys            392450  (12) lib   
 784898  (12) root   915715  (12) sbin   1046530  (12) tmp   
1046531  (12) bin    784899  (12) dev     392451  (12) mnt   
 915716  (12) run        12  (12) proc   1046532  (12) boot               13  (16) lib64   
 784945  (12) srv    915821  (12) opt       3604  (3796) vmlinuz

Directory called opt has inode 915821 and inode 2 is root of filesystem. So my chroot directory is /opt/debian-jail. Sure, /dev/sda1 may be mounted on another filesystem. You need to check that (use lsof or directly picking information /proc).

回复收藏 0 原文

~没有更多了~