Re: Authorization without permanent setuid on helper
Re: Authorization without permanent setuid on helper
- Subject: Re: Authorization without permanent setuid on helper
- From: John Davidorff Pell <email@hidden>
- Date: Sat, 22 Jan 2005 11:38:57 -0800
Please take a moment to read what I have posted, instead of relying on
Michael's misundrestanding of it. Nothing I have said conflicts with
what you have posted in retort to your misunderstanding of what I said.
All I am opposing is setting the setuid bit on helper tools, because
there are few operations that require root or that should be done
lightly. I don't think that there are, or should be, tools which run as
root at any invocation. What if an exploit is discovered in that tool,
then another applications just exec()'s it? It now has root code
running that it can exploit, though thankfully the time-window and
code-windows are small, as it is a helper tool.
If an operation should be allowed by any user of the system, which is
what a setuid tool does, then "The security model employed by Mac OS
X's BSD later" should be changed to allow it. For example, by using
group ownership information one can avoid running as root at all, which
is what System Preferences does, and we all like not having to
authenticate.
Michael likes to use the network settings example. Why on earth are you
changing your network settings all the time?? If you frequently use two
or three networks at different points of the day, then set up 3
locations: its easier, faster, and doesn't require a setuid tool
written by someone whom I personally will never install software
written by because he doesn't have a clue as to what's going on. If he
is referring specifically to AOL's pppotcptool, then I would assert
that if you need to use AOL then this is one of the setuid tools that
you just have to live with, but not for long as AOL is moving to a much
more decentralised approach which will not require route munging (I
know, I'm one of their beta testers).
JP
On 22 Jan 2005, at 03:10, Finlay Dobbie wrote:
On Fri, 21 Jan 2005 20:48:25 -0800, John Davidorff Pell
<email@hidden> wrote:
There is no need to be root to get a process list and there is no
reason to change the date or time often. I would rather be asked (more
like notified) if someone is trying to change my system clock, to use
your example. The one time that I set the clock after install, putting
in my password is absolutely acceptable.
I'm not sure that the process list thing has always been the case, but
perhaps it was a poor example
You seem to have a very static idea of the "UNIX security model".
OK, would you prefer I said "The security model employed by Mac OS X's
BSD layer"?
"The security model employed by Mac OS X's BSD later" is different from
the security model employed by FreeBSD, its closest relative, so yes
this would be a much better term to use, as it is actually specific
enough to be meaningful. Every unix flavour has different security
models, many times only with minor variations. Linux has capability to
apply many different models using kernel modules.
I would be happy so long as all possible effort is made to avoid
running something as root. If it is required to use some feature of
your program, and I as a user want that feature, then obviously I'll
live with a process running as root.
Well, duh. That's what setuid tools do. They factor out the LITTLE BIT
OF THE PROGRAM that needs to run as root into a setuid tool, which
then refuses to operate unless a valid authorization reference has
been passed in. Depending on the user's privileges (and the right
you're authorizing against) they could already be pre-authorized based
on their membership of the admin group or whatever.
Personally, I like System Preferences not requiring me to authenticate
if I'm an admin user - I've already authenticated the fact that I have
the credentials to perform the operations.
Anyway, I'm just saying that your assertion, implied or otherwise,
that nothing ever needs to run as root and anything that should run as
root should need your explicit permission to do so is one that I
disagree with.
By the way, what about StartupItems and kernel extensions? Should you
have to authorize every single one of those at boot by typing your
password? They certainly get super-user privs by default.
Or should you just have to do it once, at installation? Sounds more
sane to me.
-- Finlay
--
Every time you share on a P2P network, God kills a kitten.
Please think of the kittens.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden