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.

What you are talking about is practical experience, and observation. The exact details regarding chroot() do indeed vary by implementation, and therefore, cannot be safely assumed.

As opposed to me demanding you accept my mortal words, I will refer you to a URL that seems to be quite valuable with regard to this topic. Yes, the easiest exploits involve the user running as root. This should not be taken for granted. Additional precautions are necessary.

http://www.unixwiz.net/techtips/chroot-practices.html

I agree that the details of what happens when you have UID 0 inside a chroot environment vary from system to system. Essentially, problem is that you have an unstoppable force (root) up against an immovable object (chroot), and the results of these situations are always tricky...

For all other UIDs, though, behavior is consistent between systems. The URL you mention agrees with this, and my experience agrees with this. As long as you code carefully, know its limits, and are not UID 0, chroot does what it says it will, and is no more of a "clever hack" than any other system call.

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.";

Consider the issue with Linux. The reason '.' can be used to escape from a chroot() environment is because '.' is not special. '.' is a hard link to current directory. In operating systems that implement chroot() to be 'more secure', '.' must be special cased.

Specifically, '.' and '/..' must be special cased. In the simplest form, this may mean that '/.' and /..' need to be translated in place on reference to appear as if they both referred to '/'.

But if, after chroot()'ing, "." acts differently for root than it does for every other user, then isn't root being treated as a special case? Mustn't there be a check against the uid somewhere? That's the special case I'm talking about.

It seems to me that you are saying, on Linux, in a chroot() environment, '.' is a special case for every user except root... I suppose you might look at it that way, but it seems a bit backward and I still don't understand where the reduction in code complexity comes from.

Regarding '..', I don't understand why that would be any more of a special case than it usually is (that is '/..' being equivalent to '/').

I'm sure I'll have to start digging through source code before I understand your point.

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