Beefy Boxes and Bandwidth Generously Provided by pair Networks Frank
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: Re: Re: Re: exiting a chroot environment

by sauoq (Abbot)
on Jul 08, 2003 at 03:51 UTC ( #272189=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Re: exiting a chroot environment
in thread exiting a chroot environment

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


Comment on Re: Re: Re: Re: exiting a chroot environment
Re: Re: Re: Re: Re: exiting a chroot environment
by MarkM (Curate) on Jul 09, 2003 at 01:41 UTC

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

        I believe the conflict in our understanding is in each of our understanding on where the /.. = /. = / magic is implemented. My understanding of the file system structures tells me that /.. = /. = / is implemented at mkfs time, not at run time. The '..' and '.' entries in '/' both refer to the same inode as '/' refers to. There is no special magic in the kernel.

        It is possible that I am incorrect, however, I suggest to you that my understanding is the only understanding that explains why Linux allows users to escape a chroot() jail by referring to '.' and './..'.

        UPDATE:

        I think we are both wrong. I can't seem to escape the Linux chroot() jail in any of the ways listed above unless '.' was already outside the chroot() jail, which is the exploit that the man page refers to.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://272189]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (15)
As of 2014-04-16 16:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (433 votes), past polls