Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!swrinde!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: rock-and-roll [Re: Retaining file permissions] [long]
Message-ID: <19088@rpp386.cactus.org>
Date: 7 Mar 91 01:07:44 GMT
References: <7391@mentor.cc.purdue.edu>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Followup-To: misc.test
Distribution: usa
Organization: Lone Star Cafe and BBS Service
Lines: 54
X-Clever-Slogan: Recycle or Die.


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.