Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!purdue!mentor.cc.purdue.edu!sage.cc.purdue.edu!asg From: asg@sage.cc.purdue.edu (The Grand Master) Newsgroups: comp.unix.internals Subject: rock-and-roll [Re: Retaining file permissions] [long] Keywords: chmod, sed, awk... and good old *cat*! Message-ID: <7391@mentor.cc.purdue.edu> Date: 6 Mar 91 18:22:42 GMT Sender: news@mentor.cc.purdue.edu Reply-To: asg@sage.cc.purdue.edu (The Grand Master) Distribution: usa Organization: Purdue University Lines: 110 The following is a letter I mailed that our friend at MIT would not post for me (Our news poster was screwed up). This is on the same subject: To: jik@athena.mit.edu Subject: Re: Retaining file permissions Newsgroups: comp.unix.shell In-Reply-To: <1991Mar1.173548.8371@athena.mit.edu> As my newsreader is not working corectly, I would appreciate it if you would post this for me - thanx Bruce In article <1991Mar1.173548.8371@athena.mit.edu> you write: }In article <7191@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: }|> You said (paraphrased) that we must turn off the suid bit upon write to }|> a non-executable file less someone chmod that file to make it executable. }|> I said (now listen, this is very simple) }|> If they can chmod it to executable, they can chmod it to suid. } } This is an ASSUMPTION. Can you prove, exhaustively, that if a user can, }through some security hole, make a file executable on a Unix system, it }follows that they can also make it setuid? I also cannot prove exhaustively that the equation x^3 + y^3 = z^3 has no non-trivial solutions. I do however realize that it is true. It is not logical to even dream that it would be possible to change one bit on a file permission without being able to change any of them. Unless of course, YOU were the one who wrote and compiled the Kernal - You'd problably put in a provision for that just to show me up. } } I'll say it again, because apparently you didn't read it the first time }(despite the fact that you quoted all of it in your posting) -- WE DON'T KNOW }WHAT FORM SECURITY HOLES TAKE. If we knew their form, we would FIX THEM. It We do not know, that is correct. However, we can use our brains a little to filter out ridiculous ones. I suppose you have all the terminals at your sight bolted down lest someone gain a root shell by rotating their terminal 20 degrees. }is QUITE POSSIBLE that there is a security hole which would allow someone to }make a file that they do not own executable, while not allowing them to make It is also quite possible that someone could turn on the suid bit without being able to turn on the execute bit. Do you therefore suggest we have the execute bit turned off upon a write to a file? } }|> Your reasoning is therefore faulty } } My reasoning is fine. You appear to have absolutely no grasp of the concept }of "hedging your bets." Your argument appears to be that we don't need to }protect ourselves against security holes we don't know about because we know }there aren't any security holes we don't know about. That just doesn't wash. There is a difference between hedging your bets, and being so paranoid that you waste valuable time and resources on non-existant holes. Note: Read my original post, and you will note that I never once advocated leaving the suid bit on in this situation, but just that you explaination of someone setting the execute bit was ridiculous. } }|> Or is that too hard for an MIT student to understand } } Please, spare the insults. They're unnecessary, and to be honest, in this }particular situation, I think they're making you look like a fool. } Oh gee, I'm sorry. Didn't mean to hurt your feelings. I just get upset with people who post BEFORE they think. $ ls file rwsrw-rw- root 561 Feb 28 12:48 file $ cat breakin-program > file $ chmod o+x file $ ls file rwsrw-rwx root 561 Feb 28 12:48 file $ ls /bin/chmod #I bet this is an MIT system rwsrwsrwx root 732 Jan 28 00:00 /bin/chmod $ echo Yes, it is an MIT system Bruce Varney The Grand Master p.s. Don't get offended, it is nothing personal sar.casm \'sa:r-.kaz-*m\ \sa:r-'kas-tik\ \-ti-k(*-)le-\ n [F sarcasme, fr. LL sarcasmos, fr. Gk sarkasmos, fr. sarkazein to tear flesh, bite the lips in rage, sneer, fr. sark-, sarx flesh; akin to Av thwar*s to cut] 1: a cutting, hostile, or contemptuous remark : GIBE 2: the use of caustic or ironic language - sar.cas.tic aj jik@athena never did give any comments on this article, just a reply with some name-calling stating that he would not post it --------- sar.casm \'sa:r-.kaz-*m\ \sa:r-'kas-tik\ \-ti-k(*-)le-\ n [F sarcasme, fr. LL sarcasmos, fr. Gk sarkasmos, fr. sarkazein to tear flesh, bite the lips in rage, sneer, fr. sark-, sarx flesh; akin to Av thwar*s to cut] 1: a cutting, hostile, or contemptuous remark : GIBE 2: the use of caustic or ironic language - sar.cas.tic aj ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##