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

-

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/h...)

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)!

-

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)!

-

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
-

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
-

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

-

It can.
Please re-read my previous msg.
-serge

-

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?

-

No.  If you unshare your mounts namespace immediately before pivot_root,
-serge

-

Bugger.  You're right, I didn't read your previous message; I thought I 
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?

-

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:
I argue chroot is buggy.  Miloslav's patch might not be the right

solution, but he has the right idea (i.e. fix it.)

-

The root directory, '/' is changed, and if the process is capable of using
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
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 
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 
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

-

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
-

but why there keep 1000001th. It is same as:
-

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
-

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

-

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

-

On Wed, 26 Sep 2007 01:05:07 +0930
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)

-

On Wed, 26 Sep 2007 01:05:07 +0930
Debugging and testing. At least that is as I understand it much of where
A fence with 10000 open gates is not improved by turning it into a fence

with 9999 open gates.

-

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

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
-

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
-

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

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

Kyle Moffett
-

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

-

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

-

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.

-

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.

-

Of course.  chroots are not a stack, they're just a point in the
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.

-

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.

-

On Wed, Sep 26, 2007 at 01:21:08AM -0400, Kyle Moffett wrote:
Since 2.6.20, it was even simpler :

   mount -t proc proc /proc

   cd /proc/1/cwd
Cheers,

Willy
-

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

-

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

-

And yet it is the dot-dot entry which is used to access files outside 
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.

-

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

-

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

have not you?

-

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);

-

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

-

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.

-

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

-

so we remain in chroot.

-

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 
-

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

-

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

-

yes, but I can use fds from chroot ;-) ....

-

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

-