Products > Computers

GNU/Linux: why doesn't chroot() really protect?

(1/3) > >>

chroot() is a function usually implemented as "command", whose binary is usually "/bin/chroot", and it's usually part of sys-apps/coreutils, intended to limit access to a filesystem by changing its root, so, after chroot($xxx) a process will see only those which are limited at the top-level by the $xxx parameter passed to the chroot().

--- Code: ---    char_t root_name[]="/stage/stage4-2008-04";
    /* do chroot() */
    if( ans isNotEqualTo 0)
        panic(module, fid, "probably wrong", root_name);

--- End code ---
(user space application)

chroot() needs a kernel syscall, which invokes "set_fs_root()" for a process. In no way chroot()  limits the syscalls a process can make! It's not a sandbox! It's not a virtualizer! It simply "sets" the root in the info structures passed to a process (usually /bin/bash).

Using chroot mainly to use very old rootfs (e.g. 2008 Stage4 on modern 2024 kernels) without having to resort to a virtual machine or anything else!

--- Code: ---bind { /dev /proc /sys } /stage/stage4-2008-04
chroot /stage/stage4-2008-04 /bin/bash
source /etc/profile

--- End code ---
I also use chroot to compile a new rootfs, and to test it.

And right here I was told that ... chroot() is not the best choice for "testing" a rootfs because "an exploit" (evil code) could very well reach even /etc/passwd.

This is because chroot() does not in any way limit access to inodes outside the new root.

What other vulnerabilities does it have? Has anyone ever seen a real exploit?

From 'man 2 chroot':

--- Quote ---This  call changes an ingredient in the pathname resolution process and does nothing else.  In particular, it
is not intended to be used for any kind of security purpose, neither to fully sandbox a process  nor  to  re-
strict  filesystem system calls.  In the past, chroot() has been used by daemons to restrict themselves prior
to passing paths supplied by untrusted users to system calls such as open(2).  However, if a folder is  moved
out  of  the  chroot directory, an attacker can exploit that to get out of the chroot directory as well.  The
easiest way to do that is to chdir(2) to the to-be-moved directory, wait for it to be moved out, then open  a
path like ../../../etc/passwd.

A  slightly trickier variation also works under some circumstances if chdir(2) is not permitted.  If a daemon
allows a "chroot directory" to be specified, that usually means that if you want to prevent remote users from
accessing files outside the chroot directory, you must ensure that folders are never moved out of it.

--- End quote ---

Stages1-4 ? Folders are never moved out of the chrooted!

Is there any other vulnerability?

Well, if you are able to run mknod while in a chroot you have access to devices you may not normally have access to.

Chroot(2) was never intended to be a security mechanism, and it isn't, there are many ways around it.

If you want the nitty gritty details, read the first part of Robert's and my Jail paper:


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod