tneff@bfmny0.UU.NET (Tom Neff) (05/01/90)
In article <1203@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes: >TODAY'S HELPFUL HINT: If you need to do something special with the setup >or installation of your software distribution (e.g. chmod, uudecode, >etc.), please provide a ten-line sh script in the archive rather than >making it part of the shar archive itself. I agree except that 'chmod +x' ought to be allowed. It's common already, and basic to making scripts executable. That exact syntax could be standardized for simulation elsewhere. >Not rhetorical: would shar format be an appropriate topic for an RFC? I think so. Someone 'major' would have to do it.
chip@chinacat.Unicom.COM (Chip Rosenthal) (05/01/90)
In article <518@cpsolv.CPS.COM> rhg@cpsolv.uucp (Richard H. Gumpertz) writes: > [ in response to my flame that smart shar's are evil and rude ] While my original message was certainly a flame, this isn't. I do have some disagreements in areas I feel strongly about. It's just too much blood has been spilled trying to get a safe unbundler running, and tired of every clown who comes up with a wonderful new shar format which adds nothing but breaks unbundlers. >Rather than just flame, how about writing a good unshar that does enforce >reasonable security by interpreting the shar script itself instead of passing >it off to sh? There aren't all that many commands to worry about. Unfortunately, that is not the case. As you pointed out earlier in the message: >You provide awk and sed but refuse to provide fgrep? How is the latter any >more dangerous? It isn't any more dangerous. The question is do I have to provide an entire filesystem of bin utilities just in order to let a lousy shar package unbundle itself? For the record, I wish awk weren't in my list. >Alternatively, perhaps better, how about providing to the world an unshar >package that sets up the environment that you mention above and runs a >chroot'ed sh under it? Now that might be useful! That's *exactly* what I'm doing. (If you'd like a copy, I'd be glad to send one.) So-called smart shar archives just make things more difficult. OK, so now some bucko decides he has a better shar maker, it just needs fgrep and chmod. What next...tar and cpio? Fsck? By far the *worst* of the smart shar archives are those which try to be cute and split files across multi-part archives so that they are all the same length. This is just anal to the max. I never used to be able to handle these because I'd do "zcat Part01.sh.Z | unshar" and then "zcat Part02.sh.Z | unshar", and part2 would fail because ark1isdone is no longer in the unshar tmp directory. (I eventually gave in and hardwired recognition of .Z suffixes on the unshar command line.) Yes, I can (and do) handle every one of these complexities. However, you reach a point where it's just easier to have a junk system out back to do unshar's on rather than providing a utility to do it. TODAY'S HELPFUL HINT: If you need to do something special with the setup or installation of your software distribution (e.g. chmod, uudecode, etc.), please provide a ten-line sh script in the archive rather than making it part of the shar archive itself. >By the way, I am now using shar 3.11 (with my own extensions to do file >compression) as a handy method for transferring files between my own accounts >on machines that are connected only by multi-hop UUCP. That's a neat tool. But that's not a shar appropriate for distribution. Look, the purpose of a shar archive is really simple - to provide a bunch of files in a self-extracting format. Most of the whizzy features people throw into their shar archive do nothing to enhance this base purpose. They are just crap...err...unrequired features. Now, this isn't an absolute. The shar's I make aren't just "cat<<'EOF'". I do use sed, wc, and test (and mkdir if required). But that's it. I also justified to myself the added complexity of each "improvement". I wish more folks would. Keep it simple. Please?!!?? Not rhetorical: would shar format be an appropriate topic for an RFC? -- Chip Rosenthal | You aren't some icon carved out chip@chinacat.Unicom.COM | of soap, sent down here to clean Unicom Systems Development, 512-482-8260 | up my reputation. -John Hiatt
peter@ficc.uu.net (Peter da Silva) (05/02/90)
I still fail to understand the security concerns of shars, apart from the
single case of comp.mail.maps.
Look at it this way... after you have carefully unpacked the shar in the
controlled environment of your chrooted directory tree, and so on, you're
going to then compile and run the stuff inside. Even fixing portability
problems by carefully answering questions from long interactive shell
scripts that you know you never bother to examine. If I was writing a
trojan horse I wouldn't put it in the shar, I'd put it in "Configure",
"build", "install", or whatever. Or even in the code... see my little
"Usenet Virus" posting, recently published in comp.virus.
I don't know. It's like worrying about potential carcinogens in the *label*
on your TV dinner.
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>
/ \ 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com>
\_.--._/ Disclaimer: commercial solicitation by email to this address
v is acceptable.tneff@bfmny0.UU.NET (Tom Neff) (05/02/90)
In article <FQ53S_xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I still fail to understand the security concerns of shars, apart from the >single case of comp.mail.maps. It's not *just* security, although that's part of it. It's also reliability, portability and overall safety (not just protection against malice). Shell archives should not do strange crap. They should do the absolute minimum necessary to create a fileset on minimally POSIX-ish systems, while LOOKING uniform in structure so that non-Bourne extractor programs can understand them. I would allow only six basic operations: create file, create directory, mark executable, verify integrity, echo to user and abort. Additional information, like file modes, times etc, can be placed into special header lines which are just comments to the shell: #%# Name=sample.1 Mode=0644 Uid=101 Gid=5 Size=2194 Mtime=04617601375 #%# Chksum=011240 Typeflag=0 Uname=tneff Gname=other in a standardized format where a *smart* unshar utility (which should itself be promulgated widely) can recognize it and do more precise extraction as and if the user wants it. Someone asked whether there should be an RFC for shell archives. I think there should. It should then be subsumed into P1003.whoever. The above header format fits in fairly well with the direction they seem to be moving, although someone can probably clean it up. This other trend, where people create shell archives that try to rewind your magtape and put the cat out, is bogus. -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.UU.NET
tp@mccall.com (05/02/90)
In article <1203@chinacat.Unicom.COM>, chip@chinacat.Unicom.COM (Chip Rosenthal) writes: > In article <518@cpsolv.CPS.COM> rhg@cpsolv.uucp (Richard H. Gumpertz) writes: >> [ in response to my flame that smart shar's are evil and rude ] > For the record, I wish awk weren't in my list. Me too, because I don't have awk. > By far the *worst* of the smart shar archives are those which try to be > cute and split files across multi-part archives so that they are all the > same length. This is just anal to the max. I never used to be able to I still can't handle them. > Yes, I can (and do) handle every one of these complexities. However, you > reach a point where it's just easier to have a junk system out back to > do unshar's on rather than providing a utility to do it. I can't handle most of this stuff. I work on it occasionally. I have a bunch of shar's I can't unpack yet. > Now, this isn't an absolute. The shar's I make aren't just "cat<<'EOF'". > I do use sed, wc, and test (and mkdir if required). But that's it. I also > justified to myself the added complexity of each "improvement". I wish > more folks would. Keep it simple. Please?!!?? These I can handle. > Not rhetorical: would shar format be an appropriate topic for an RFC? ABSOLUTELY! PLEASE! I wanted to post this to agree with just about everything Chip said for entirely different reasons. There is a lot of shar format software posted to the net that I'd like to use, or at least look at (the README's aren't always near the beginning. I have a slight problem with shar's, however. I run VMS (please avoid the temptation to flame VMS, as it is not appropriate to this discussion). I don't have sh, or any of the other utilities. shar format is not self-unpacking under VMS. I do have an unshar program (came with my uucp, but I've patched it a little) that can handle simple shar's (I'd guess about 50% of what I've tried it on). I intend to make it a little better. I don't intend to emulate or write awk (it can do a little sed, enough to handle most shar's). There is no way I can, or even want to, keep up with all these fancy shar programs. chroot doesn't buy me anything, and I don't have fgrep, awk, etc. Anything you add to your shar, I have to be able to write C code to understand it or I can't unpack your shar. I also don't feel like spending my life working on shar. I can always unpack it by hand, if it is worth it (which it rarely is). I'm not asking you to use shar's that VMS likes. I'm just pointing out another reason to keep shar's simple. I don't mind using an unshar program to unpack them, but please don't go out of your way to break the thing. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
wht@n4hgf.uucp (Warren Tucker) (05/02/90)
In article <1203@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes: >In article <518@cpsolv.CPS.COM> rhg@cpsolv.uucp (Richard H. Gumpertz) writes: >> [ in response to my flame that smart shar's are evil and rude ] > >While my original message was certainly a flame, this isn't. I do have I said I wasn't gonna say anything else on this topic. But, alas, ... >By far the *worst* of the smart shar archives are those which try to be >cute and split files across multi-part archives so that they are all the >same length. This is just anal to the max. Anal? Anal? Most of the anal types I know would have it squirting out all over if they thought one of their files had been split up by a program. It is merely a side effect that the shar sizes are similar; the purpose is to limit the size to accommodate mail systems or other transport mechanisms. Somebody in the history of this evil neo-pseudo-shar thought it a disk-consuming limitation that you had to have disk temporarily available for the entire shar set, the file parts it unwraps AND the target reconstructed files. I agree with him. >>You provide awk and sed but refuse to provide fgrep? How is the latter any >>more dangerous? > >It isn't any more dangerous. The question is do I have to provide an >entire filesystem of bin utilities just in order to let a lousy shar >package unbundle itself? Why not? I do. As a matter of fact, the programs in /bin have been tested to the satisfaction of most. The shell scripts unwrapped by the shar are _probably_ going to have access to /bin ;->. >Look, the purpose of a shar archive is really simple - to provide a bunch >of files in a self-extracting format. Most of the whizzy features people >throw into their shar archive do nothing to enhance this base purpose. >They are just crap...err...unrequired features. To you, then, perhaps a shell should check a program name against an approved list of programs and execute it, passing arguments as is. Other features are unnecessary. >Now, this isn't an absolute. The shar's I make aren't just "cat<<'EOF'". >I do use sed, wc, and test (and mkdir if required). But that's it. I also >justified to myself the added complexity of each "improvement". I wish >more folks would. Keep it simple. Please?!!?? Oh, ok, you do recognize the need for ...err... features. Please allow others to justify to themselves the need for "additional complexity". All of the features I've seen in any shar producer are really quite simple. >Not rhetorical: would shar format be an appropriate topic for an RFC? Now, _that_ is anal. If you are worried by the commands I use to deliver source to you, you will probably be terrified of the fact that system calls are in that source. My advice is to let us keep our shars and if your amniotic membrane won't let the source inside, just rm and forget it. You don't need the trauma. Jeez, at least shell and editor wars had some religious validity. But shar wars? ------------------------------------------------------------------ Warren Tucker, TuckerWare gatech!n4hgf!wht or wht%n4hgf@gatech.edu McCarthyism did to cinema what ANSI did to C, cast a great number of characters into the void.
faigin@aerospace.aero.org (Daniel P. Faigin) (05/03/90)
In article <15441@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > In article <FQ53S_xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >I still fail to understand the security concerns of shars, apart from the > >single case of comp.mail.maps. > It's not *just* security, although that's part of it. It's also > reliability, portability and overall safety (not just protection against > malice). Shell archives should not do strange crap. They should do the > absolute minimum necessary to create a fileset on minimally POSIX-ish > systems, while LOOKING uniform in structure so that non-Bourne extractor > programs can understand them. > I would allow only six basic operations: create file, create directory, mark > executable, verify integrity, echo to user and abort. There are still major security concerns about this. Suppose you had an unshar program that only allowed cat and chmod. That's it. You still have risks... 1. The program could create arbitrary setuid programs. If you run as root, you've just opened the door wide. 2. The program could trash arbitrary files, either by writing garbage over them or to the end, or by nullifying the contents of the file. 3. The program could cripple the system, by removing access to files that need to be accessable to all users. 4. The program could copy arbitrary files in your directory somewhere else, and then make these files readable by everyone. Classic trojan horse. Shars are dangerous, and unshar programs don't get around the problem. Daniel. -- [W]:The Aerospace Corp M1/055 * POB 92957 * LA, CA 90009-2957 * 213/336-8228 [H]:9758 Natick Avenue * Sepulveda CA 91343 * 818/892-8555 | If you turn it [Em]:faigin@aerospace.aero.org * Faigin@dockmaster.ncsc.mil | over and don't [Vmail]:213/336-5454 Box#3149 | let it go, you end up upside down
tneff@bfmny0.UU.NET (Tom Neff) (05/03/90)
In article <FAIGIN.90May2120834@sunstroke.aerospace.aero.org> faigin@aerospace.aero.org (Daniel P. Faigin) writes: >There are still major security concerns about this. Suppose you had an unshar >program that only allowed cat and chmod. That's it. You still have risks... ^^^^^^^ You need have no more risks than the unshar program is willing to allow. It could prevent setuid stuff, writing out of the current subtree, etc. >Shars are dangerous, and unshar programs don't get around the problem. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This doesn't take my previous proposal into account. (Did the poster read it?) If standardized header information were provided as shell #comments, then an also-standardized unshar program could read a shar as effortlessly as a tar file, and with equally faithful results. Under this scheme there would be no "operations" at all, just file and directory creation. By imposing appropriate limits on what "Mode=" and "Name=" is allowed to be, unshar could operate safely.
peter@ficc.uu.net (Peter da Silva) (05/03/90)
In article <15441@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > Someone asked whether there should be an RFC for shell archives. I think > there should. I don't. I think there should be an RFC for *text* archives. And I think it should specify something a bit more formal than a shar. The Software Tools text archive format is admirably suited to the purpose. (Where is Brian Kernighan when we need him?) -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Commercial solicitation *is* accepted by email to this address.
peter@ficc.uu.net (Peter da Silva) (05/03/90)
> Shars are dangerous, and unshar programs don't get around the problem.
Nope. *Software* is dangerous. And the software *inside* the shar is a
much bigger concern than the shar. If nothing else, you keep it longer.
--
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>
'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com>
@FIN Commercial solicitation *is* accepted by email to this address.