Freaky as it seems, you can on Linux¹ (Red Hat.)

From chroot(2):

Note that this call does not change the current working directory, so that `.' can be outside the tree rooted at `/'. In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'.

I've confirmed that I can do it in perl with another chroot() to ./../../ (with enough ..s to get me to the real root from the CWD.) I guess "." isn't just symbolic?

Ick.

Thankfully, that's not portable. Other systems are sane.

1. I figured I'd look at the manpage to see if it said "you can't do that" and much to my surprise...

-sauoq
"My two cents aren't worth a dime.";

I wouldn't be as quick to declare that this is a Linux failing point. There are no guarantees made by any system that chroot() will ensure that exploits are not possible. chroot() is a UNIX hack to redefine /, and this is where its claim ends. If one truly wants a box to contain a user, one should consider using a virtual machine of some sort.

It isn't that 'other systems are sane', but rather, 'other systems implement chroot() as a more elaborate hack.' The cost, of course, is performance, and code complexity. Is Linux wrong for not choosing this path? I don't believe so. I believe it is wrong for people to assume that silver bullets to their security problems exist... :-)

AFAIK, the guarantee provided by all Unix systems is that non-root users can't escape from chroot. I can't find a good reference, but that's always been my understanding of this system call. root's limitations in chroot vary by operating system.

It's safe to trust chroot as long as you drop root before executing untrusted code.

It isn't that 'other systems are sane', but rather, 'other systems implement chroot() as a more elaborate hack.' The cost, of course, is performance, and code complexity.

I really don't know. I haven't looked at any code. I don't care that much, but I am curious. How would it be a "more elaborate hack" to avoid special-casing root? How would it result in more code complexity or less performance? I doubt performance is an issue in any case, but I would think that Linux's behavior would result in more code complexity.

I believe it is wrong for people to assume that silver bullets to their security problems exist.

I absolutely agree. (And I never even mentioned security in the first place.)

Maybe "sane" wasn't the right choice of words. Frankly, I was just surprised as I wasn't familiar with that behavior. I don't really see much advantage to it, but I guess I don't see much harm either. *shrug*

-sauoq
"My two cents aren't worth a dime.";

Urg. I didn't realize Linux behaved so oddly. Yet another reason not to worship Linux (don't get me wrong, I make my money as a "Linux specialist"). Not only is Linux behaviour not portable, the entire chroot concept isn't. chroot is not part of the POSIX standard.

Abigail

Not that I am arguing in favour of Linux worship but the chroot man page does say that the linux implementation conforms to a number of standards "CONFORMING TO SVr4, SVID, 4.4BSD, X/OPEN. This function is not part of POSIX.1." and the OpenBSD chroot man page also states that "There are ways for a root process to escape from the chroot jail". Without actually comparing code it is impossible to say one way or another but on the surface it would appear that the Linux implementation is not that "odd".

--
Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho