If unpriviledged user could do chroot(2), she could do something like this:

mkdir -p my_root/lib
cp /lib/* my_root/lib
cp my_evil_libc_replacement/libc.so my_root/lib
ln /bin/passwd my_root/passwd
chroot my_root passwd

Et voila, your own library loaded into suid process.

If your cwd is inside the chroot() space, if you chdir(".."), you'll keep going up the tree, but will be stopped once you reach the top of the chroot(). The reason you're stopped is that your cwd is the root of the chroot(), and that's the special case the chroot() code looks for to prevent you from going up the tree.

If you're superuser, though, you can run chroot() from within a chroot(). If you chroot() to a subdirectory, this changes the notion of "root of the chroot()." Your cwd is now above that root. If you try to chdir(".."), you can now go to the parent of the cwd. You can iteratively walk your way all the way up to the original root.

The punchline: If your cwd is in the chroot space, chdir() can't take you out of the chrooted space. If your cwd starts outside the chroot space, nothing forces you into the chroot space. Because chroots don't nest, root can escape chroot by chrooting to a subdirectory, thereby placing cwd outside the chroot.

As for not letting mortal users chroot()... If the mortal user has write access on any filesystem containing system binaries and files, they can hard-link to those binaries and files inside the chroot "jail" ahead of time. They can then put other files of their own creation in choice places (e.g. replace libc as someone suggested, or change other configuration files) and run SUID programs that are "too trusting" (e.g. programs that don't check for UID or GID=0 on libraries or config files) and get them to misbehave.

Note that such an attack is much more difficult (impossible?) if mortal users do not have writable directories on the same filesystem as system libraries, executables and configuration scripts. Hard links generally do not cross filesystem boundaries.

--
Program Intellivision and play Space Patrol!

The problem is that you're seeing small things in a discussion without having the background information.

".." always means the same thing. Chroot works like this:
1. Create or mount a new rootdir somewhere inside your current one
2. make that your new root dir using 'chroot'

Say the old structure is:

/blah
/blah/chrootdir

Now you do:
chroot /blah/chrootdir /bin/bash

You are now in a bash shell in /blah/chrootdir - except that on the virtual filesystem, /blah/chrootdir appears to be '/' and not '/blah/chrootdir'.
So, when you do a ".." from '/' you get the expected behavior - the directory does not appear to change. Buggy behavior would be to put you into the directory '/blah' when you do '..' from '/' inside chroot. This behavior is different from what is expected of symlinked directories, but in all cases ".." means the same thing - the parent directory. It's just that in the given case of chroot, '/blah/chrootdir' is its own parent - which is what we want. In fact if that wasn't the behavior, a million other things will break and I wouldn't be able to do my job.

I heard methods for escaping from chroot() jails years and years and years ago. That someone is showing up now going "OMG EXPLOIT" is worthy of a "Hey, do your homework first." Reminds me of that ancient Dilbert strip...

That said, FreeBSD and other UNIXes apparently has extended chroot in ways that help, but still aren't a panacea. That's fine and all, but if you walk in expecting those extensions to be standard behavior on another OS, you should be prepared for disappointment rather than going around telling kernel hackers they're wrong.

--
Program Intellivision and play Space Patrol!

I didn't see the comments as rude. The original poster was incorrect in believing there was a bug. It appears that the original poster didn't bother to read about 'chroot' and its expected behavior.

Thank goodness we can.

There have been a few times were installing Linux or doing other such things I've needed to break out of chroot to fix something or other.

Only root can break out of a chroot(). But the language is a misnomer, because chroot() was never meant to confine root in a security sense. Its like saying, "The warden can break out of a local prison". Well, I would hope so.

This may be apocryphal, but IIRC originally any user could use chroot(); it was a convenience interface. Only later were the semantics altered in *NIX so the kernel would only honor a chroot() call if the process' uid was 0. It was a small alteration to a simple system call which became useful to creating secure daemon applications in a very narrow sense.

Non-root users cannot break out of a chroot. The normal way to use chroot to lock down a network daemon is to use chroot + privilege separation. A simple example for a web server:

1) Start daemon as root.

2) bind() to port 80.

3) pw = getpwnam("luser"); assert(pw->pw_uid != 0). You can't do that after you chroot() because you shouldn't be able to see /etc/passwd.

4) chdir("/somewhere"). Also, be careful you have no open directory descriptors or other file descriptors the process shouldn't have while operating with reduced privileges. Think about where stdin, stdout and stderr are directed. Maybe you close all descriptors from 3 to getdtablesize(), excepting the ones you need (like the socket descriptor).

5) chroot("/somewhere") safe without any binaries, particularly no SUID binaries; ideally a file system that doesn't honor the SUID bit at all (often a /var partition if the sysadmin is diligent). You may need duplicates of things like /etc/resolv.conf, /dev/null, /dev/zero. (NOTE: If you're super paranoid you might want to chroot() to a filesystem that doesn't even allow device files.)

6) setuid(pw->pw_uid) (or setgid(pw->pw_gid); setuid(pw->pw_uid)).

7) accept() connections.

There are lots of other tricks to making sane *NIX process daemons, like how to fork, keeping/using parent watchdogs, syslog() v. stderr, advanced privsep techniques (i.e. descriptor passing), etc. There's no single way to do it in general; it needs to be narrowly tailored to the unique demands. However, there is only one way to use chroot() to lock down a process. In brief: chdir() + chroot() + setuid().

Yes, you are missing something -- and you aren't the only one to miss it. The folks who get it aren't missing it, but lots of other folks who are confused are.

The key is that there are two chroots under discussion. There's the system call chroot(2), and there is the administration command chroot(8). chroot(8) uses chroot(2) to do the key work, but other than that, it's not implicated in this "bug" at all.

The description of chroot(2) in its man page is particularly telling:

chroot() changes the root directory to that specified in path. This directory will be used for pathnames beginning with /. The root directory is inherited by all children of the current process.

Only a privileged process (Linux: one with the CAP_SYS_CHROOT capability) may call chroot(2).

This call changes an ingredient in the pathname resolution process and does nothing else.

This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a 'chroot jail' by doing 'mkdir foo; chroot foo; cd ..'.

This call does not close open file descriptors, and such file descriptors may allow access to files outside the chroot tree.

There are so many security issues mentioned in those few lines that its surprising that anyone might think chroot(2) is supposed to be for security.

Basically, chroot(2) changes the pathname resolution in this way (assuming that the current "root" directory is /chroot):
1) for absolute pathnames, interpret them as if they were prepended with /chroot. e.g. "/usr/bin" is treated as "/chroot/usr/bin"
2) for relative pathnames, interpret ".." in the "root" directory as pointing to the "root" directory.

This means that if an application made the following system calls:
chdir("/chroot"); chroot("/chroot"); FILE f = open("../etc/passwd");
then f would refer to /chroot/etc/passwd, since the .. from /chroot would be caught and made to refer to /chroot

However, if an application did the following:
chdir("/usr"); chroot("/chroot"); FILE f = open("../etc/passwd");
then f would refer to /etc/passwd, since the .. from /usr would not be redirected to /chroot.

The "bug" being highlighted here (which is incredibly old behavior, predating Linux by a long shot) is based on the idea that chroot(2) only muddles with pathname resolution and that a process only has a single chroot. This allows a process to use chroot(2) to "escape" if it knows what its doing.

So assuming that a process is being run "securely" chrooted to /chroot, the following sequence of calls will allow it to access /etc/passwd:
chdir("/"); mkdir("/foo"); chroot("/foo"); FILE f = open("../etc/passwd");
after the chdir("/") call, the current working directory would be /chroot. The mkdir() call creates /chroot/foo, and the chroot() call sets the current root to /chroot/foo, and the current working directory is still /chroot. The open() call tries to open /chroot/../etc/passwd using a relative path that does not pass through the current root /chroot/foo, so it doesn't get modified by the chroot call, and effectively accesses /etc/passwd without a problem.

In fact, except for the most pathological chroot jails the following system call sequence will reset chroot to the real root:
chdir("/"); mkdir("foo"); chroot("/foo"); chroot("../../../../../../../../../../../../../../../../../../../../../../..");

The question is: is this a bug, and if so, should it be fixed?

Alan's answer is simple: no, it's not a bug; it's how chroot(2) has worked historically in unices past, it's how it's documented to work, and chroot(2) was never intended to be secure. It's so full of security holes anyway patching this isn't worth it. Besides, it's only a problem if you can use chroot(2), which only root can do anyway. Once you've got a black-hat executing arbitrary code as root, keeping them from escaping a "chroot jail" is the least of your problems.

After all, a program running as root, even in a chroot jail, could just as easily mount a procfs or devfs within the chroot jail -- and access the contents without restriction. That's the keys to the kingdom.

chroot(8) is different. It doesn't allow the user to use chroot(2) in anything but a structured way, roughly equivalent to the first set of system calls I gave (the chdir("/chroot"); chroot("/chroot"); sequence), which ensures that you are properly "jailed". But if you can run your own program as root that can call chroot(2) directly, that program can "escape" without a problem.

chroot is also broken if an admin creates you an empty password file and leaves a copy of "su" laying around. This example in particular doesn't imply that the unix authentication scheme is a broken technology.

just use mount --bind

i.e:
mkdir /chroot2/olddata
mount --bind /chroot1/data /chroot2/olddata
chroot /chroot2 ...

IIRC chroot was introduced in 4.3 or 4.2BSD as an aid in _building the system_. Compilation. Not a security feature of any kind. It can be used as a security thing, but it's not neccessarily a good idea. Jail, on the other hand, or the Solaris Zones - yeah, these were introduced as a security features.

I think that chroot can be used as a security tool(?) but isn't designed for this purpose.

Chroot (while not designed as a security tool) can provide an element in a DiD (Defense in Depth) strategy. It is certainly much less strong than many other elements you should have, and it is not appropriate in some cases. I am sure it would not be difficult to find examples of other technologies which were not designed with security in mind which are useful as an element in a DiD strategy.

Ultimately, security needs to be about a knowledgeable person putting in place a series of measures to make something hard to break into. Chroot may or may not be useful in any given circumstance, but certainly should never be RELIED upon by itself.

Always remember that there are times when ADDING a layer REDUCES security (double-pass XOR encryption anyone?). Somebody previously pointed out that if you don't need root for your process, adding chroot means you also need to add root access at some stage, which is dangerous.