Hello,

here is an fix to an exploit (obtained somewhere in internet). This

exploit can workaround chroot with CAP_SYS_CHROOT. It is also possible

(with sufficient filedescriptor (if there is na directory fd opened in

root) workaround chroot with sys_fchdir. This patch fixes it.
Miloslav Semler

On Wed, 19 Sep 2007 09:19:50 +0200
If you have the ability to use chroot() you are root. If you are root you

can walk happily out of any chroot by a thousand other means.
Alan

-

I thought this was to prevent breaking out of chroot as a normal user.

	ie. chroot /var/myjail /bin/su - guest

or similar.
--

Bill Davidsen <davidsen@tmr.com>

   "We have more to fear from the bungling of the incompetent than from

the machinations of the wicked."  - from Slashdot

-

Normal users cannot use chroot() themselves so they can't use chroot to

get back out

-

I think Bill is right, that this is to fix a method that non-root

processes can use to escape their chroot. The exploit, which is

documented in chroot(2)*, is to chdir("..") your way out. Who'd have

thought it? Only root can do that, but even that seems wrong. Chroot

should be chroot and that should be the end of it.
It looks to me like Miloslav has found a bug, although I suspect there's

a simpler solution because non-root is already prevented from escaping

this way.
David
* In particular, the superuser can escape from a ‘chroot jail’ by doing

‘mkdir foo; chroot foo; cd ..’.
-

No, he can not.
-

On Fri, 21 Sep 2007 13:39:34 -0400
The superuser can escape that way - its expected and fine behaviour

-

Does not work for me, and that would be the EXACT thing chroot is

supposed to prevent.  Maybe you guys are thinking of a program that

calls chroot() but leaves cwd outside the chroot still being able to

navigate outside of it?
-

Oh, for fsck sake...  Folks, it's standard-required behaviour.  Ability

to chroot() implies the ability to break out of it.  Could we please

add that (along with reference to SuS) to l-k FAQ and be done with that

nonsense?
If you are within chroot jail and capable of chroot(), you can chdir to

its root, then chroot() to subdirectory and you've got cwd outside of

your new root.  After that you can chdir all way out to original root.
Again, this is standard behaviour.  Changing it will not yield any

security improvements, so kindly give that a rest.

-

I'm pretty confident that it's only standard behavior for Linux.  Every

other unix says it's not allowed.

-

On Wed, 26 Sep 2007 20:04:14 +0930
So how about reading up on the subject instead?  
*spends five minutes with Google*
From the OpenBSD FAQ (an operating system most know for being really,

really focused on security):
    http://www.openbsd.org/faq/faq10.html
    Any application which has to assume root privileges to operate is

    pointless to attempt to chroot(2), as root can generally escape a

    chroot(2).
Solaris:
    http://www.softpanorama.org/Solaris/Security/solaris_privilege_sets.shtml
    You must be root to make the chroot() call, and you should quickly

    change to non-root (a root user can escape a chroot environment,

    so if it's to be effective, you need to drop that privilege).
A chroot FAQ:
    http://www.unixwiz.net/techtips/chroot-practices.html
    There are well-known techniques used to escape from jail, but the

    most common one requires root privileges inside the jail.
Another chroot FAT one linked to from the previous one:
    http://www.bpfh.net/simes/computing/chroot-break.html
    This page details how the chroot() system call can be used to

    provide an additional layer of security when running untrusted

    programs. It also details how this additional layer of security

    can be circumvented.
    Whilst chroot() is reasonably secure, a program can escape from

    its trap.
Yet Another FAQ, this time about secure Unix Programming:
    http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/
    chroot() only limits the file system scope and nothing else.
    [further descriptions of how to break out of chroot, with and

    without root privileges]
Convinced?
  /Christer
--

"Just how much can I get away with and still go to heaven?"
Christer Weinigel <christer@weinigel.se>  http://www.weinigel.se

-

For sure, "a root user can get out of a chroot a million different

ways."  Young Alan said as much at the beginning of this conversation,

and I have always agreed.  I don't hope to secure Linux within chroot,

simply to fix chroot so that it does what it says it does.
Look, when chroot was being designed, I think they intended that even

root should be unable to get out.  They went so far as to say that

dot-dot wouldn't let you out; and it doesn't.  It's not dot-dot that's

the problem.  Even fchdir is no problem, because you choose which file

descriptors to leave open.  Fchdir is actually one of the answers.

("What if we need a way to escape?")
The problem is leaving cwd unchanged.  Once you've set cwd within the

new root, dot-dot is promised to keep you within that root; and so it

does.  But by leaving cwd unchanged, if you do a subsequent chroot, that

promise is suddenly broken.  I think this is a bug.  I think that

behavior was not intended.  Not all agree with me, but obviously a lot

do, otherwise OpenBSD and others wouldn't have addressed this exact

issue.  Here's what they do:
    "If the program is already running with an altered root directory,

    the process's current directory is changed to the same new root

    directory.  This prevents the current directory from being further

    up the directory tree than the altered root directory."

    -- OpenBSD man 2 chroot
This was no more than an attempt to fix a long-standing bug.
As stated, opinion is divided as to whether this is a bug.  I think it

is, and many people agree, for example some of the BSDs and probably

others; some people don't.  Young Alan, for example, ummm, strongly (is

a good word) disagrees.  I don't see that it calls for nastiness or

emotion, and although opinion on this august list is divided, apparently

the nays are in the majority.  We should leave it at that.

-

On Thu, 27 Sep 2007 06:49:28 +0930
So keep reading the links I gave you:
    http://www.unixwiz.net/techtips/chroot-practices.html
    The chroot call itself does not change the working directory, so

    if the new root is below the current directory, the application

    can still have access outside resources.
    http://www.bpfh.net/simes/computing/chroot-break.html
    chdir("/foo/bar");

    chroot("/foo/bar");
    Note the use of the chdir() call before the chroot() call. This is

    to ensure that the working directory of the process is within the

    chroot()ed area before the chroot() call takes place. This is due

    to most implementations of chroot() not changing the working

    directory of the process to within the directory the process is

    now chroot()ed in.
    http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/
    The chroot() call itself will only change the root file system in

    the process' context. A chroot() call must be followed by a

    chdir("/") call in order to reset the current working directory.
So the OpenBSD man page seems to be in the minority here.  Any portable

code can not assume that CWD changes.  And changing the Linux behaviour

now would be a rather big change which might break userspace.  And yes,

there are applications that rely on this, I've used it when building

software for cross compiling.  
  /Christer
On Thu, 27 Sep 2007 06:49:28 +0930

-

Changing Linux behavior would violate the POSIX and SuSV2

specifications; the standards explicitly state that the working

directory will NOT change.  And standards adherance is important; we

break them only if we have a d*mn good reason.  And trying to make

chroot() something which it is not (i.e., a secure jail) is certainly

not a good enough reason.
Can we please end this thread now?  And can we put in a Kernel FAQ

saying that this is not something which is NOT up for discussion?
       	    	    		  	   - Ted

-

It seems there are (at least) two parts to this, one regarding changing

working directory which is clearly stated in the standards and must work

as it does, and the various issues regarding getting out of the chroot

after the cwd has entered that changed root. That second part seems to

offer room for additional controls on getting out of the chroot which do

not violate any of the obvious standards, and which therefore might be

valid candidates for discussion on the basis of benefit rather than

portability.
--

bill davidsen <davidsen@tmr.com>

  CTO TMR Associates, Inc

  Doing interesting things with small computers since 1979
-

Correct.  BSDs solved the problem by changing cwd on subsequent use of

chroot; I think there's a better way.  I think the solution might be to

add a "previous root", and restrict the process there as well as the new

root.  That is, once cwd is set within the new root, that new root is

the limit.  Prior to setting cwd within the new root, the previous root

is the limit.

-

You are claiming "They went so far as to say that dot-dot wouldn't let

you out"?
Who are the "they" people you are referring to?
And where did "they" explicitely state what you claim they did say?
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

I phrased it in a somewhat conversational way.  The promise, which I've

-

You claimed:
<--  snip  -->
Look, when chroot was being designed, I think they intended that even root

should be unable to get out. They went so far as to say that dot-dot

wouldn't let you out; and it doesn't.
<--  snip  -->
You were clearly saying that whom you call "they" were the people who

designed chroot. And it was you who was claiming in this statement that

"they" said it.
The OpenBSD manpage you quoted in this thread states chroot() was added

in 4.2BSD, and 4.2BSD was released in 1983.
You should therefore either bring a source where the people who designed

chroot() in 1983 or earlier are stating what you claim they said or

admit that you were talking utter bullshit.
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

You've ignored the operative phrase, "I think".

-

So you start a paragraph with "Look, when chroot was being designed" and

all the contents of this paragraph only comes from your imagination and

contradicts the facts...
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
-

chroot() is present in v7, thank you very much.  /usr/sys/sys/sys4.c has
chdir()

{

        chdirec(&u.u_cdir);

}
chroot()

{

        if (suser())

                chdirec(&u.u_rdir);

}
and back then it didn't stop lookups by .. at all - u_rdir is only used

in the beginning of namei() (when pathname starts with /), plus the obvious

refcounting in exit()/newproc().  So give me a break - back when it had

been introduced, it didn't do anything jail-like _at_ _all_.
That check appears only in BSD:

@@ -1,4 +1,4 @@

-/*     vfs_lookup.c    4.4     03/06/81        */

+/*     vfs_lookup.c    4.5     81/03/09        */
 #include "../h/param.h"

 #include "../h/systm.h"

@@ -107,6 +107,9 @@

        u.u_segflg = 1;

        eo = 0;

        bp = NULL;

+       if (dp == u.u_rdir && u.u_dent.d_name[0] == '.' &&

+           u.u_dent.d_name[1] == '.' && u.u_dent.d_name[2] == 0)

+               goto cloop;
 eloop:
with spectaculary lousy commit message ("lint and a minor fixed") by

wnj.  Feel free to ask Bill Joy WTF he had intended.  At a guess,

more consistent behaviour in chrooted environment (i.e. pathname

resolution looking as if the subtree had been everything).
To talk about root-safety of _anything_ at that point is bloody ridiculous.

-

OK, the possibilities are

	* you've discovered a bug in all Unices (BTW, even FreeBSD *does*

allow to break out of some chroots in that fashion; RTFS and you'll see -

just pay attention to setting fdp->fd_jdir logics in kern/vfs_syscalls.c:

change_root(); it sets jail boundary on _first_ chroot and if you've got

nested chroots, you can leave them just fine by use of SCM_RIGHTS to hold

directory descriptor).  All hail David, nevermind that this behaviour had

been described in Unix FAQs since _way_ back.

	* you've misunderstood the purpose of chroot(), the fact that

behaviour in question is at the very least extremely common on Unix and

the fact that any code relying on root-proof chroot(2) is broken and needs

to be fixed, simply because chroot is _not_ root-proof on (at least) almost

all systems.
Note that the last statement applies in both cases; it's simply reality.

Insisting that behaviour known for decades is a bug since it contradicts

your rather convoluted reading of the standards...  Looks rather silly,

IMO, but that has zero practical consequences anyway.  Userland code can't

rely on root-proof chroot(2), period.

-

On Wed, 26 Sep 2007 20:04:14 +0930
Go try them, then come back and admit your error

-

I've made no error.  The documentation says what it says, and what it

doesn't say, other than for Linux, is that there is an unspecified way

of breaking out.
If you're so keen on trying things, then I challenge you to try it on,

oh, say, BSD, and then admit your error.  (Such hostile words.)

-

Now see I've been working on Unix systems since 1988 or so and in that

time I've learned to read the documentation properly (you haven't) and

I've also don't security work on a pile of systems. Your assumptions and
FreeBSD isn't a Unix system, and isn't compliant to the spec. Its

also still trivial to get out of a freebsd chroot using things like

ptrace. FreeBSD jails on the other hand do what you confusedly seem to

think should happen with chroot. They are seperate precisely because they

are different.
Alan

-

My, my, you can be unpleasant when you try.  There's no need for it.  As

it happens I have years of UNIX experience on you.  (Newbie!)
You've got an idea that the original intention was for there to be a way

to escape from a chroot, but that the documentation was written so that,

not only was this not mentioned, but what was written implies

otherwise.  You've also got some idea that because it's the way it is,

therefore it must be right.  You present no reasoning to explain why the

behavior is correct; instead you use insults.  I've exhausted my

tolerance for rudeness.

-

Well if citing standards documents at people is rudeness so be it.
Alan

-

Alan,
Did you just tell a porky?  Did you just (again) say something

calculated to give a false belief?  I think so.
That was you implying that standard documents say things that they

don't.  But yes, that was the first time.
Care to let it drop?
David

-

You quoted the standard, I merely pointed out you forgot to read it

properly. Thats your problem not mine.
Alan

-

How bizarre.  Last email you claimed to quote the standards (but you

never did.)  Your becoming an embarrassment.  You were rude, and

multiple times.  Please just drop it while you retain a shred of dignity.

-

** Plonk **
Welcome to my killfile.
-

Well that's a relief.

-

I hate to get involved in this, but actually chroot() is no longer part

of SuS as of version 3.
For other Unix versions, both Tru64 (5.1B) and Solaris (9) chroot(2) man

pages also say the working directory is unaffected by chroot().  The

Solaris man page explicitly mentions using fchdir() to reset the root to

a previously opened directory however.
On Tru64 and Solaris, the chroot command does call chdir() after

chroot(), but that is a userspace thing.

-