asg@sage.cc.purdue.edu (The Grand Master) (03/07/91)
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 ### #
;-) # #
;'> # ##jik@athena.mit.edu (Jonathan I. Kamens) (03/07/91)
In article <7391@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: |> 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: |> |> ... |> |> jik@athena never did give any comments on this article, just a reply |> with some name-calling stating that he would not post it What I said in my E-mail was: |You probably can't post because the References line is too long and |you're using an old version of rn that can't cope with long References |lines. Trim the References, and you should be able to post. | |In any case, if you can't post that way, then find someone else to |post your message for you. I'm not in the habit of doing favors for |people I don't even know who have been obnoxious to me without |provocation. I see no reason to respond any further to Mr. Varney's comments, because I see no reason to drag personal squabbles onto the net, and because I don't see any points raised in his posting that I have not already covered in my postings. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
jfh@rpp386.cactus.org (John F Haugh II) (03/07/91)
The attribution of this article is completely screwed up. Apologies are made in advance to everyone involved ... In article <7391@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (The Grand Master) writes: >In article <1991Mar1.173548.8371@athena.mit.edu> (Jonathan Kamens) write: >} 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? > > 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. Your logic is fairly correct - the ability to change the mode bits of a file via some random security hole would seem to imply that you are able to change any mode bit whatsoever, including the setuid mode bits. This is all very true, but also very boring. What you have done is assumed that the problem exists, and therefore stated that the problem probably exists - that is, assume the existence of a security hole that would allow you to change any single bit in the permissions and that same security hole would allow you to change a specific bit. You are going from the general to the specific, and that little transformation is always permitted when making arguments of this nature. >}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? You are arguing a straw man - execute permission grants NOTHING that =read= permission does not grant us. In particular because =read= permission allows us to copy the file and then set the execute permission on the file which we know own. On the other hand, the setuid bit does grant additional permission and that privilege should be contained in some fashion. You are arguing apples and oranges. Clearing the write bit costs you nothing - the ability to modify a binary which you could have copied and modified yourself. Clearing the setuid bit costs you a completely different something - the ability to become another user running an arbitrary executable. >jik@athena never did give any comments on this article, just a reply >with some name-calling stating that he would not post it And well he shouldn't. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
torek@elf.ee.lbl.gov (Chris Torek) (03/07/91)
>In article <7391@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu >(The Grand Master) writes: >> The following is a letter I mailed that our friend at MIT would not >> post for me (Our news poster was screwed up). ... In article <1991Mar6.234727.23298@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) defends himself a bit. I would like to add that I probably would not have posted that particular article for Mr. Master either (and how did you get a first name like `The' anyway? :-) ). As it happens, this particular barn door was closed after a horse had escaped. There is no sense in arguing that `write not clearing set-id could not possibly be a security problem', because it was. One could perhaps argue that `it is not now a security problem', but I would not want to bet my systems on it. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
asg@sage.cc.purdue.edu (Bruce Varney) (03/07/91)
In article <1991Mar6.234727.23298@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: }In article <7391@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes: }|> 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: }|> }|> ... }|> }|> jik@athena never did give any comments on this article, just a reply }|> with some name-calling stating that he would not post it } }What I said in my E-mail was: } }|You probably can't post because the References line is too long and }|you're using an old version of rn that can't cope with long References }|lines. Trim the References, and you should be able to post. }| }|In any case, if you can't post that way, then find someone else to }|post your message for you. I'm not in the habit of doing favors for }|people I don't even know who have been obnoxious to me without }|provocation. } }I see no reason to respond any further to Mr. Varney's comments, because I see }no reason to drag personal squabbles onto the net, and because I don't see any }points raised in his posting that I have not already covered in my postings. } }-- }Jonathan Kamens USnail: You NEVER covered my points made in that article, and this is not a personal squabble. I automatically save outgoing mail and had not cleaned those files, so when I saw the discussion resumed, I dug it out as an informative post (as it was). Simply put Jon, you need to learn to distinguish between guarding against real security hazards, and wasting time preventing impossible ones. I hope you do not have the same ideas in the real world, or you would never do anything. Please do not resort to accusing people of using the net for personal squabbles to draw attention from the fact that you are losing an argument. --------- 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 ### # ;-) # # ;'> # ##
asg@sage.cc.purdue.edu (Bruce Varney) (03/07/91)
In article <10710@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >>In article <7391@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu >>(The Grand Master) writes: >>> The following is a letter I mailed that our friend at MIT would not >>> post for me (Our news poster was screwed up). ... > >In article <1991Mar6.234727.23298@athena.mit.edu> jik@athena.mit.edu >(Jonathan I. Kamens) defends himself a bit. I would like to add that I >probably would not have posted that particular article for Mr. Master >either (and how did you get a first name like `The' anyway? :-) ). Read on and you would have found my real name. Our system has a specification for a Real name, and a Nickname. Unfortunatly, Pnews uses my Nickname instead of my Real name (My Nickname obviously being "The Grand Master"). Since several people such as yourself have found that too hard to comprehend, I have changed my "Nickname" to my real name. Happy? :-) > >As it happens, this particular barn door was closed after a horse had >escaped. There is no sense in arguing that `write not clearing set-id >could not possibly be a security problem', because it was. One could >perhaps argue that `it is not now a security problem', but I would not >want to bet my systems on it. My contention is that it is no longer necessary to clear the suid bit on NON-EXECUTABLE FILES! Jon put forth that non-executables had had the suid bit clear to prevent security violations. I merely suggest that this is not the case, but that the reason this behavior still exists is because it would be a time and resource consuming to modify the kernal to check if the file had an execute bit set before deciding to clear the suid. >-- >In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427) >Berkeley, CA Domain: torek@ee.lbl.gov --------- 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 ### # ;-) # # ;'> # ##
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/07/91)
In article <7431@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (Bruce Varney) writes: > My contention is that it is no longer necessary to clear the suid > bit on NON-EXECUTABLE FILES! Joe compiles a setuid program and sets it up: cc -o foo foo.c chmod u+s foo # oops, umask is 002, better keep that file safe from carelessness by group chmod g-w foo # and make it available... chmod g+x foo Sally, in the same group and doing work in the same directory, writes something to foo after the setuid bit has been turned on. Guess what? In your world, foo is still setuid. Contentions about theoretical behavior are cute, but this is the real world. Machines have real users who make real mistakes. Your proposed change that would increase the chance of mistakes and has no obvious advantages. It should never be adopted. Please stop blabbering about security holes now. ---Dan
asg@sage.cc.purdue.edu (Bruce Varney) (03/07/91)
In article <12596:Mar707:44:2791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: }In article <7431@mentor.cc.purdue.edu> asg@sage.cc.purdue.edu (Bruce Varney) writes: }> My contention is that it is no longer necessary to clear the suid }> bit on NON-EXECUTABLE FILES! } }Joe compiles a setuid program and sets it up: } } cc -o foo foo.c } chmod u+s foo } # oops, umask is 002, better keep that file safe from carelessness by group } chmod g-w foo } # and make it available... } chmod g+x foo } }Sally, in the same group and doing work in the same directory, writes }something to foo after the setuid bit has been turned on. Guess what? In }your world, foo is still setuid. Thank you Dan. You have provided me with an explaination I was looking for. My contention all along was that there was some other reason than than put forth by Jon as to why the suid bit was cleared on non-executables. His explaination was incorrect, but yours is correct. My problem was with his contention that there was a way to turn on the execute bit without being able to turn on the suid bit. My contention was that if you can change one you can change them all. But your explaination makes sense and I thank you for a rational explaination to the question at hand. NOTE: my comments here are NOT sarcastic --------- 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 ### # ;-) # # ;'> # ##
zink@panix.uucp (David Zink) (03/08/91)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: (About not-clearing suid bits upon writes to non-executable files) > Contentions about theoretical behavior are cute, but this is the real > world. Machines have real users who make real mistakes. Your proposed > change that would increase the chance of mistakes and has no obvious > advantages. It should never be adopted. You pedantic twit. Try your example in the real world and see what happens. > Joe compiles a setuid program and sets it up: > Sally, in the same group and doing work in the same directory, writes Joe is the J prompt and Sally is the S prompt. J> cc -o foo foo.c J> chmod u+s foo S> find /etc -print > foo J> # oops, umask is 002, better keep that file safe from carelessness by group Of course, umask is obviously 013, at least. J> chmod g-w foo J> # and make it available... J> chmod g+x foo > Please stop blabbering about security holes now. > ---Dan Now fix all the security holes as per Dan's perfect world. J> cc -o foo foo.c S> find /etc -print > foo J> # oops, umask is 002, better keep that file safe from carelessness by group Of course, umask is obviously 013 J> chmod g-w foo J> chmod u+s foo J> # and make it available... J> chmod g+x foo Please stop blabbering now. ---David Unix is _not_ designed to protect stupid users from their stupidity. It is designed to make useful work possible. For added fun, have joe set umask 022 before starting. No hole in either case. _I_ know, setting suid should delete executable files, that'll make Dan happy.
terryl@sail.LABS.TEK.COM (03/11/91)
In article <1991Mar8.004700.27664@panix.uucp> zink@panix.uucp (David Zink) writes: +brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: +(About not-clearing suid bits upon writes to non-executable files) +> Contentions about theoretical behavior are cute, but this is the real +> world. Machines have real users who make real mistakes. Your proposed +> change that would increase the chance of mistakes and has no obvious +> advantages. It should never be adopted. + +You pedantic twit. Try your example in the real world and see what +happens. + +> Joe compiles a setuid program and sets it up: +> Sally, in the same group and doing work in the same directory, writes +Joe is the J prompt and Sally is the S prompt. + +J> cc -o foo foo.c +J> chmod u+s foo +S> find /etc -print > foo Bad example; how about this one???? S> cp /bin/sh foo;./foo Now Sally has a shell running under Joe's userid, which is probably NOT what he wanted. Depending on how malicious Sally is, she could delete ALL of Joe's files. Sounds like a real BIG security hole to me.... +J># oops, umask is 002, better keep that file safe from carelessness by group +Of course, umask is obviously 013, at least. No it's not, only in your mind. You haven't provided ANY information to lead us to this conclusion. +J> chmod g-w foo +J> # and make it available... +J> chmod g+x foo Lord knows I've dinged Dan in the past, but this time he is 100% correct. If you don't think it's a security hole, can I have an account on your machine where the set-user-id bit is NOT cleared on writes???? It's also interesting to note that you directed followups to alt.flame and some other alt.<newsgroup>. You really didn't think we would fall for that old trick now, did you???? __________________________________________________________ Terry Laskodi "There's a permanent crease of in your right and wrong." Tektronix Sly and the Family Stone, "Stand!" __________________________________________________________