Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!munnari!moncskermit!basser!metro!nswitgould!tony
From: tony@nswitgould.OZ (Tony McGrath)
Newsgroups: net.unix-wizards
Subject: Re: chroot(2) security
Message-ID: <376@nswitgould.OZ>
Date: Tue, 7-Oct-86 13:10:56 EDT
Article-I.D.: nswitgou.376
Posted: Tue Oct  7 13:10:56 1986
Date-Received: Wed, 8-Oct-86 20:10:51 EDT
References: <158@itcatl.UUCP> <113@nonvon.UUCP> <15879@ucbvax.BERKELEY.EDU>
Organization: Comp Sci, NSWIT, Australia
Lines: 89

In article <15879@ucbvax.BERKELEY.EDU>, ballou@brahms.BERKELEY.EDU (Kenneth R. Ballou) writes:
> Wait a minute, now it's *my* turn to be missing something here.  *Which*
> /bin/login?  If the root directory is now actually /mnt23/user/test, then
> presumably we would be trying to execute /mnt23/user/test/bin/login, not
> the /bin/login that is setuid root and which is able to log a user in.

This is essentially correct, however all is not quite as it seems.

Chroot changes the interpretation of what file paths starting with / will
actually refer to. This makes life interesting, to be sure.

If you chroot to /mnt23/user/test, then that becomes the root for your
program and for any of its children, and that includes execs. You cannot
chroot back to anything below /mnt23/user/test as you cannot reference a
file below the current root using a full pathname.

There is, however, one interesting feature of chroot. It doesn't change
your current working directory. Thus you can still access files relative
to the current working directory that your program had, either by chdir
before the chroot, or by inheriting from the shell.

Therefore the following scenario would be interesting.

1. Create a temporary directory (/mnt23/user/temp).

2. Create two sub-directories (/mnt23/user/temp/etc & /mnt23/user/temp/bin)

3. Create a dummy password file in /mnt23/user/temp/etc/passwd.

4. Copy over /bin/sh to /mnt23/user/temp/bin/sh (for login).

5. Create a program to chroot("/mnt23/user/temp") and 
   then execl("../../../bin/login", "login", 0).

6. Wait for the shell, and voila!, SuperUser!!!

This, however, doesn't seem to work on our system. Execl fails to start
login and the whole scenario fails spectacularly.

I tried some other chroot programs. I put a copy of ls and sh in my home
directory and then ran a chroot program to exec sh. The shell
starts in my home directory, as ls will verify (the chroot was into
/tmp) and it is possible to ls into .., ../.. etc. It is also possible
to run programs relative from my home directory. Once a chdir is done
there is no turning back, as it appears (from the shell) to go to the
root directory (/tmp).

One experiment that did work was the following:

1. Create /mnt23/user/temp and other files as in 1..4 above.

2. Copy /bin/sh into /mnt23/user/sh and cd there.

3. Compile a program that does
	a. chroot("/mnt23/user/temp");
	b. execl("sh", "sh", 0);

   This gives you a shell in /mnt23/user, rooted in /mnt23/user/temp.

4. Try ../../bin/login.

   This starts login, rooted in /mnt23/user/temp, using the file
   /mnt23/user/temp/etc/passwd as its /etc/passwd and likewise
   using /mnt23/user/temp/bin/sh as /bin/sh.

5. You are now the SuperUser, TRAPPED IN /mnt23/user/temp!!!

6. If you are clever, you would have stolen chown and chmod before
   you started this little escapade, but we all learn from our mistakes :-)

It would be fairly easy to abuse chroot in this way, hence the requirement
for SuperUser privileges for use. Of course, to do any of above one
needs to be the SuperUser ;-)

However, chroot can be useful, and the relative addressing will stop
at the chroot'ed directory once you do a chdir. I have used this as
the basis of a security area for our student population. It is wasteful
in terms of file space and system resources (as /bin/sh and /student/bin/sh
are seen to be different programs by 4.2BSD's text sharing), but it
effectively limits students to their own universe. (Now if I could only
find a way to stop them from getting access to staff logins ... :-)

Tony McGrath
New South Wales Institute of Technology

ACSnet: tony@nswitgould.oz
UUCP:	...!seismo!munnari!nswitgould!tony  (I think!)

I can't think of anything to say!