Retaining file permissions

Jonathan I. Kamens jik at athena.mit.edu
Sat Mar 2 04:35:48 AEST 1991


In article <7191 at mentor.cc.purdue.edu>, asg at 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'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
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 setuid.  Can you PROVE that such a hole does not exist?  If you can, I
suspect there's a job at the NCSC with your name written on it.

|> 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.

|> 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.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710



More information about the Comp.unix.shell mailing list