Xref: utzoo news.admin:4175 news.sysadmin:1816 comp.mail.uucp:2454 Path: utzoo!attcan!lsuc!ecicrl!clewis From: clewis@ecicrl.UUCP (Chris Lewis) Newsgroups: news.admin,news.sysadmin,comp.mail.uucp Subject: Re: Dangerous hole in Usenet! Summary: Further proposal on map unpacking. Keywords: maps unpacking unshar security hole Message-ID: <157@ecicrl.UUCP> Date: 4 Dec 88 19:25:05 GMT References: <1971@van-bc.UUCP> <572@comdesign.CDI.COM> <5517@medusa.cs.purdue.edu> <561@redsox.UUCP> <215@twwells.uucp> <155@ecicrl.UUCP> <1988Nov29.181037.23528@utzoo.uucp> Reply-To: clewis@ecicrl.UUCP (Chris Lewis) Organization: Elegant Communications Inc. (CRL Division) Lines: 94 In article <1988Nov29.181037.23528@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >>Secondly, can someone out there explain why chroot is privileged? ... >>... It seems pretty darn silly that some >>mechanism that can only be used for *reducing* access rights requires >>root permission... > >The latter sentence would be reasonable, except that it does not apply >to chroot. Chroot can expand access rights as well as reducing them, >because it gives absolute control over the file system, and some parts >of the file system are vital to the protection system. For example, >login assumes that the file it finds when it opens "/etc/passwd" is the >system password file. Thanks Henry (and literally dozens of others) for pointing out the problems of world-executable chroot. What a dumb question to ask. [I mailed out a response about the other chroot issue - if you don't get your reply soon, please resend a request from your root account] Getting back for a moment to map unpacking - I think that the point has been well made about automatic map unpacking being unsafe unless you use uuhosts or something similar. It was rather funny seeing the "but I'm safe because I use unshar" remarks, and then later those same people finding out that their unshar is *probably* (you get that? "probably" - there are literally hundreds of versions of unshar out there - don't flame me if you happen to have one of the one or two that doesn't use /bin/sh) extremely unsafe. I still think it would be a really good idea to come up with a new format for map postings, so that we don't have to go through this fuss about security holes over and over again as new SA's come online and use the easy way out. As expressed by Scot Wilcoxon (datapg!sewilco) "Actually, that's a good idea. There's no need for that single-purpose newsgroup to have contents which are so flexible as to need shar." What I propose is the following for the contents of map articles: MAP ENDMAP Where: (eg: u.can.on.1) is a simple file name - no slashes etc allowed is some tokens that would be ignored by unpacking, but could be used for other things. is a copy of the body of the map, with lines that start with things likely to cause problems (like a site "ENDMAP", or periods) prepended with an "X" (ala sed-style unshars) If there's any interest in this on the part of the keepers-of-the-maps, I'll write a small package to do this. Presumably the best way would be to distribute it along with the maps and then cut over at some future date. H'm, as a transitional step, we could do both at once. Eg: cat > << 'END-OF-SHAR' #MAP #ENDMAP END-OF-SHAR Hey, some of the maps already come out looking very much like this already: > : This is a shell archive. > : Remove everything above this line and > : run the following text with /bin/sh to create: > : u.usa.va.1 > : This archive created: Fri Dec 2 01:22:05 1988 > echo shar: extracting u.usa.va.1 > cat << 'SHAR_EOF' > u.usa.va.1 > #MAP FILE: u.usa.va.1 Thu Dec 1 16:59:15 PST 1988 rob@violet.berkeley.edu > # > # > > #N aaachoo > #S AT&T 3B2/500, Sys V 3.2 > .... > yendor hqda-ai(DIRECT+HIGH), media(DAILY), bjs(DIRECT), > arc6000(DIRECT), ozzie(DIRECT) > # > # > #MAP FILE END: u.usa.va.1 Thu Dec 1 16:59:30 PST 1988 rob@violet.berkeley.edu > SHAR_EOF Note the MAP FILE entries. -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)