Re: Authorization without permanent setuid on helper
Re: Authorization without permanent setuid on helper
- Subject: Re: Authorization without permanent setuid on helper
- From: OL&L Lists <email@hidden>
- Date: Fri, 21 Jan 2005 16:05:20 -0800
Title: Re: Authorization without permanent setuid on
helper
At 3:22 PM +0000 1/21/05, email@hidden
wrote:
M. Uli Kusterer wrote:
> When it comes to security I'd rather rely on Apple's
code that's
> been used in hundreds of projects than on me myself writing
bug-free
> and un-exploitable code.
I just wish there was more explanation of details. For instance,
from what I've studied of MoreAuthSample, it seems that someone could
substitute a malicious template in the app bundle and thus cancel out
any security protections that the template/copy approach gains you.
Unless the user (even an admin user) knows what he/she is authorizing
(a malicious helper will appear no different than the original when
authorizing), he/she could unwittingly authorize some nasty things to
happen. I hope I'm just misunderstanding how things work that
that somebody can provide the one bit of information that clears it up
for me.
> Users can use the keychain to authorize my helper
once without the
> hassle of having to re-enter the password every time.
How does this work in practice? How do you get Authorization
Services to check the Keychain first before prompting the user for a
password?
> That will even ask them to re-authorize when the app is
modified.
> Sounds safer to me.
Does this mean that the modification times on all of the folders in
the app bundle are checked? If so, that would take care of the
malicious template substitution problem.
There's just so much information
scattered all over the place on Apple's developer site that it's very
difficult to sort everything out.
Yes, and when I spoke with Apple they said that is the way they
want it.
The reason for this is they only want 'real' developers writing
root code. Basically they don't want to write one single great big
manual to show how to do it step by step because then any hackers can
just pick up one book, read it and see how it works. They *want* to
make it hard so that hackers cannot figure it out. But you can -
because you *have* to.
As for the template substitution issue, the idea is that most
people do not run their machines as admin - the idea is you run the
installer, you have to admin password to install, then once the
template is on disk, unless you are logged in as admin, you must
re-enter an admin password in order to replace (reinstall) the
software. Hence it's not so easy to replace the template. If you use
your machine logged in as admin all the time, then you have security
risks. I believe this is no different than the constant UNIX
admonition to "never run as root". Note also that MIB code
states that you may want to extend your template validation beyond
what they provide - such as digital signatures, network checks,
etc.
Please read Performing Privileged Operations with
Authorization Services from Apple. It's long but it clears up a
lot of the architecture and security issues.
Michael
Orbital Launch & Lift, Inc.
http://www.orbitallaunch.com
_______________________________________________
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