Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!math.mit.edu!drw
From: drw@fibonacci.math.mit.edu (Dale R. Worley)
Newsgroups: comp.sources.d
Subject: Safer unsharing -- why chroot() *really* doesn't work
Message-ID: <DRW.89Oct25234218@fibonacci.math.mit.edu>
Date: 26 Oct 89 03:42:18 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: MIT Dept. of Mathematics, Cambridge, MA, USA
Lines: 30

As quoted from <15018@bloom-beacon.MIT.EDU> by drw@math.mit.edu (Dale R. Worley):
+---------------
| I may be naieve, but I would think that between running sh from a
| non-root account, and use of chroot(), one would be able to confine
| the damage from a dangerous archive to just one part of the directory
| tree.  Why doesn't this work?
+---------------

To break security with chroot():

1. Invoke whatever setuid root thingy establishes the directory that
it will chroot into.

2. Have your shar script sleep a good long while at the beginning.

3. While it's sleeping, in another shell, cd to that fake root
directory.  "ln /bin/su ./bin/su" to install su in the fake /bin
directory.  Also, "cat ~/xyz ./etc/passwd" to install a fake
/etc/passwd file, one whose root password you know.

4. Now your script wakes up, "su root"s with the password you know,
and "chmod u+s /bin/sh".  Then it sleeps a while longer.

5. In the other shell, "mv ./bin/sh ~".

Voila!

Sigh,

Dale		drw@math.mit.edu