rock-and-roll [Re: Retaining file permissions] [long]

The Grand Master asg at sage.cc.purdue.edu
Thu Mar 7 04:22:42 AEST 1991


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 at athena.mit.edu
Subject: Re: Retaining file permissions
Newsgroups: comp.unix.shell
In-Reply-To: <1991Mar1.173548.8371 at 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 at athena.mit.edu> you write:
}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 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 at 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 at sage.cc.purdue.edu             ###    #####       #
PUCC                               ###                #
;-)                                 #                #
;'>                                #               ##



More information about the Comp.unix.internals mailing list