Xref: utzoo news.admin:4107 news.sysadmin:1724 comp.mail.uucp:2388
Path: utzoo!utgpu!watmath!clyde!att!rutgers!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!tytso
From: tytso@athena.mit.edu (Theodore Y. Ts'o)
Newsgroups: news.admin,news.sysadmin,comp.mail.uucp
Subject: Re: Dangerous hole in Usenet!
Message-ID: <8219@bloom-beacon.MIT.EDU>
Date: 29 Nov 88 22:11:31 GMT
References: <1971@van-bc.UUCP> <572@comdesign.CDI.COM> <5517@medusa.cs.purdue.edu> <561@redsox.UUCP> <215@twwells.uucp> <155@ecicrl.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: tytso@athena.mit.edu (Theodore Y. Ts'o)
Organization: Massachusetts Institute of Technology
Lines: 25

In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes:
>Secondly, can someone out there explain why chroot is privileged?  Or
>why /etc/chroot isn't setuid?  It seems pretty darn silly that some
>mechanism that can only be used for *reducing* access rights requires
>root permission.  If only /etc/chroot allowed anybody to run it, and
>it carefully made sure that there was a setuid(getuid()) etc before
>invoking whatever it was going to invoke, the uuhosts unshar would
>be trivial.

Suppose that /tmp is on the same partition as /; or substitute /tmp for
some other user writable directory in the same parition as su or some
other setuid program you wish to confuse.  Assume that chroot is setuid.

1) cd /tmp;mkdir bin etc; ln /bin/su /tmp/bin/su
2) create /tmp/etc/passwd with one line: "root::0:1:::"
3) ln /etc/passwd /tmp/etc/passwd.real
4) chroot /tmp su
5) append to (now) /etc/passwd.real "newroot::0:1:::"
6) GAME OVER.

That's why chroot requires setuid priviledges.....
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts'o				mit-eddie!mit-athena!tytso
3 Ames St., Cambridge, MA 02139		tytso@athena.mit.edu
			If it's for real, it isn't!