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)