Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site telesoft.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!ittvax!dcdwest!sdcsvax!telesoft!pilotti From: pilotti@telesoft.UUCP (Keith Pilotti @shine) Newsgroups: net.bugs.uucp Subject: Re: Read permission on /etc/phones Message-ID: <154@telesoft.UUCP> Date: Tue, 2-Jul-85 19:26:47 EDT Article-I.D.: telesoft.154 Posted: Tue Jul 2 19:26:47 1985 Date-Received: Fri, 5-Jul-85 05:20:23 EDT References: <472@qantel.UUCP> <170@motel6.UUCP> <> Reply-To: pilotti@telesoft.UUCP (Keith Pilotti @shine) Organization: TeleSoft, SanDiego CA Lines: 34 Keywords: tip, uucp, LCK Summary: 4.2BSD `tip' "breaks" UUCP security In article <> root@bu-cs.UUCP (Barry Shein) writes: >>From: keith@motel6.UUCP (Keith Packard) >>Subject: Re: Read permission on /etc/phones > >>The problem with tip is that, after locking the modem port, it >>setuid's back to the original invoker's uid/gid. This is >>supposed to patch the security hole surrounding shell escapes >>and file transfers. Fine but; alas; it doesn't read /etc/phones >>... Another problem this causes involves /usr/spool/uucp security and LCK files. It is desirable to have /usr/spool/uucp NOT WRITABLE by the world, as this leaves a hole for (admittedly clever) vandalism. However, with the 4.2BSD version of `tip', this causes the LCK files to be left around after `tip' exits, preventing use of the port until manual intervention by a "privileged user". `tip' creates the LCK file while SUID, and no longer has write permission in /usr/spool/uucp once it changes the UID. The LCK file therefore remains. For binary sites the only "solution" seems to be to leave this directory writable. Yuck. /+\ Keith ________________________________________________________ KEITH F. PILOTTI -- TeleSoft (619) 457-2700 x172 10639 Roselle St, SanDiego, CA 92121 (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti (ARPA) Pilotti@UCSD