Using the security framework
-
Hello!
I am making a hard drive cloner/backuper, and to do some deleting and
copying, I need to use the security framework. What I need to be able
to do is have the user type in their password one time, and then it
would give me system.privilege.admin rights until a time that they
want to unauthorized it (could be days, weeks, months, years). I have
looked through the security framework, but have not really found how
to have one system.privilege.admin authorization, and have it last a
long time. So, if anyone could point me in the right direction with
this, like what methods to use, and what parameters to use.
I'm also wondering another thing. To delete the files, I need admin
privileges, but, do I need to create a new target (e.g. a shell
script) to do the copying and then run the command (blanking on the
name) that runs the script at a given path with admin privileges. Or,
could I somehow use NSFileManager in an authorized state.
Thanks for any help!
Joe -
On Jan 3, 2009, at 6:50 PM, Joe Turner wrote:
> I am making a hard drive cloner/backuper, and to do some deleting
> and copying, I need to use the security framework. What I need to be
> able to do is have the user type in their password one time, and
> then it would give me system.privilege.admin rights until a time
> that they want to unauthorized it (could be days, weeks, months,
> years). I have looked through the security framework, but have not
> really found how to have one system.privilege.admin authorization,
> and have it last a long time. So, if anyone could point me in the
> right direction with this, like what methods to use, and what
> parameters to use.
If you pre-authorize an admin authorization, then it will last for 300
seconds and then must be renewed. This is not something you can
programmatically change; it's set in the computer's /etc/authorization
file.
> I'm also wondering another thing. To delete the files, I need admin
> privileges, but, do I need to create a new target (e.g. a shell
> script) to do the copying and then run the command (blanking on the
> name) that runs the script at a given path with admin privileges.
> Or, could I somehow use NSFileManager in an authorized state.
You have to have something else do the work, since the security model
of Mac OS X (and all Unix-like OSes) do not allow the escalation of
privileges in an existing task.
Nick Zitzmann
<http://www.chronosnet.com/> -
At 18:50 -0600 3/1/09, Joe Turner wrote:
> I am making a hard drive cloner/backuper, and to do some deleting
> and copying, I need to use the security framework. What I need to be
> able to do is have the user type in their password one time, and
> then it would give me system.privilege.admin rights until a time
> that they want to unauthorized it (could be days, weeks, months,
> years). I have looked through the security framework, but have not
> really found how to have one system.privilege.admin authorization,
> and have it last a long time. So, if anyone could point me in the
> right direction with this, like what methods to use, and what
> parameters to use.
One way to do this is to have a second tool that runs as root. You
need to ask for admin permissions the first time to enable suid mode
on the tool, but after that the tool will run as root with full
privileges.
Naturally, this has all the inherent security implications of that of
any suid root tool, and the tool must now defend against possible
misuse. Some security suggestions include:
* Code sign both your application and your tool and verify both
signatures before applying the suid bit.
* Strictly limit the actions of the tool.
* Ensure requests to the tool are processed only if they come from
your properly signed application.
* Strictly minimize the tools code to minimize the chance of security
related bugs.
* Limit the use of external frameworks in the tool to minimize the
chance of security issues.
Enjoy,
Peter.
--
Keyboard Maestro 3 Now Available!
Now run macros from your iPhone with Keyboard Maestro Control!
Keyboard Maestro <http://www.keyboardmaestro.com/> Macros for your Mac
<> <<A href="http://download.stairways.com/">http://download.stairways.com/> -
On 07/01/2009 05:36, "Peter N Lewis" <peter...> wrote:
> At 18:50 -0600 3/1/09, Joe Turner wrote:
>> I am making a hard drive cloner/backuper, and to do some deleting
>> and copying, I need to use the security framework. What I need to be
>> able to do is have the user type in their password one time, and
>> then it would give me system.privilege.admin rights until a time
>> that they want to unauthorized it (could be days, weeks, months,
>> years). I have looked through the security framework, but have not
>> really found how to have one system.privilege.admin authorization,
>> and have it last a long time. So, if anyone could point me in the
>> right direction with this, like what methods to use, and what
>> parameters to use.
>
> One way to do this is to have a second tool that runs as root. You
> need to ask for admin permissions the first time to enable suid mode
> on the tool, but after that the tool will run as root with full
> privileges.
>
> Naturally, this has all the inherent security implications of that of
> any suid root tool, and the tool must now defend against possible
> misuse. Some security suggestions include:
>
To avoid some of the problems with using a setuid tool, you can use launchd
to run the privileged process as root. See the B.A.S. readme:
http://developer.apple.com/samplecode/BetterAuthorizationSample/listing4.ht
m
l
> * Code sign both your application and your tool and verify both
> signatures before applying the suid bit.
>
> * Strictly limit the actions of the tool.
>
> * Ensure requests to the tool are processed only if they come from
> your properly signed application.
>
> * Strictly minimize the tools code to minimize the chance of security
> related bugs.
>
> * Limit the use of external frameworks in the tool to minimize the
> chance of security issues.
>
These are still all good ideas. Another thing to do is to convert the Auth
Services rights structure into an external form, and pass it to the helper -
the helper then only performs privileged operations if it agrees that it has
received the authorisation.
Cheers,
Graham.
--
Graham Lee
Senior Macintosh Software Engineer, Sophos Plc.
+44 1235 540266
http://www.sophos.com/
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20. -
On Jan 6, 2009, at 10:45 AM, Nick Zitzmann wrote:
>
> On Jan 3, 2009, at 6:50 PM, Joe Turner wrote:
>
>> I am making a hard drive cloner/backuper, and to do some deleting
>> and copying, I need to use the security framework. What I need to
>> be able to do is have the user type in their password one time, and
>> then it would give me system.privilege.admin rights until a time
>> that they want to unauthorized it (could be days, weeks, months,
>> years). I have looked through the security framework, but have not
>> really found how to have one system.privilege.admin authorization,
>> and have it last a long time. So, if anyone could point me in the
>> right direction with this, like what methods to use, and what
>> parameters to use.
>
> If you pre-authorize an admin authorization, then it will last for
> 300 seconds and then must be renewed. This is not something you can
> programmatically change; it's set in the computer's /etc/
> authorization file.
That makes sense, but then how does an app like SuperDuper! do it. You
click the lock, enter your password, and then you don't need to enter
your password again until you lock it again. And, it is the regular
security framework password window, so the developer must be doing
some sort of authorization that lasts forever. And I checked, it does
authorize system.privilege.admin.
>Makes sense. So, if I create a separate target for the unix script, do
>
>> I'm also wondering another thing. To delete the files, I need admin
>> privileges, but, do I need to create a new target (e.g. a shell
>> script) to do the copying and then run the command (blanking on the
>> name) that runs the script at a given path with admin privileges.
>> Or, could I somehow use NSFileManager in an authorized state.
>
>
> You have to have something else do the work, since the security
> model of Mac OS X (and all Unix-like OSes) do not allow the
> escalation of privileges in an existing task.
I need to add something to it that takes the authorization? Or will
anything it does that uses admin files be allowed?
Thanks a lot!
Joe
>
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
>
>
>
-
On 20/01/2009, at 12:56 PM, Joe Turner wrote:
> That makes sense, but then how does an app like SuperDuper! do it.
> You click the lock, enter your password, and then you don't need to
> enter your password again until you lock it again. And, it is the
> regular security framework password window, so the developer must be
> doing some sort of authorization that lasts forever. And I checked,
> it does authorize system.privilege.admin.
The padlock is an SFAuthorizationView and it handles some of this,
although I've not used it myself.
--
Rob Keniger -
On Jan 19, 2009, at 7:56 PM, Joe Turner wrote:
> That makes sense, but then how does an app like SuperDuper! do it.
> You click the lock, enter your password, and then you don't need to
> enter your password again until you lock it again. And, it is the
> regular security framework password window, so the developer must be
> doing some sort of authorization that lasts forever. And I checked,
> it does authorize system.privilege.admin.
There is no authorization that lasts forever. Either it's polling to
keep the authorization alive (which may theoretically work, though
I've never tried it), or it forgot to set the authorization view to
auto-refresh the authorization status (which I think has to be done in
code).
> Makes sense. So, if I create a separate target for the unix script,
I wouldn't really recommend running shell code with root privileges as
a user other than root. That can be a security hole waiting to happen,
since changes to the user's environment will affect the script. AEWP()
executes things with root privileges, but not _as_ root (so it'll be
executed as the user). There are workarounds to this, but the best
workaround is to just avoid this if at all possible.
> do I need to add something to it that takes the authorization? Or
> will anything it does that uses admin files be allowed?
Once you run something with AEWP(), it has root privileges.
Nick Zitzmann
<http://www.chronosnet.com/> -
Thanks again for the speedy responses!
On Jan 20, 2009, at 1:47 AM, Nick Zitzmann wrote:
>
> On Jan 19, 2009, at 7:56 PM, Joe Turner wrote:
>
>> That makes sense, but then how does an app like SuperDuper! do it.
>> You click the lock, enter your password, and then you don't need to
>> enter your password again until you lock it again. And, it is the
>> regular security framework password window, so the developer must
>> be doing some sort of authorization that lasts forever. And I
>> checked, it does authorize system.privilege.admin.
>
>
> There is no authorization that lasts forever. Either it's polling to
> keep the authorization alive (which may theoretically work, though
> I've never tried it), or it forgot to set the authorization view to
> auto-refresh the authorization status (which I think has to be done
> in code).
I see. Then, how would you suggest to create a cloner/deleter, if it
needs root privileges, but cannot use the security framework?
What I did a bit ago was, from the command line (NSTask) call a sudu
and then run ditto or rsync, and used a pipe to give it the password.
I had a custom password view where the user entered their password.
The only thing is, I am trying to make external shell scripts
unneeded, which is why I originally just wanted to use NSFileManager.
And, since running scripts from root is dangerous, then is there any
good way to be able to delete protected (not your user account) files?
Or, should I just have it copy or delete files the user has access to?
Or is there a way other than the security framework to delete files
the user does not have access to.
Thank you again for all your help!
Cheers,
Joe Turner
>
>
>> Makes sense. So, if I create a separate target for the unix script,
>
> I wouldn't really recommend running shell code with root privileges
> as a user other than root. That can be a security hole waiting to
> happen, since changes to the user's environment will affect the
> script. AEWP() executes things with root privileges, but not _as_
> root (so it'll be executed as the user). There are workarounds to
> this, but the best workaround is to just avoid this if at all
> possible.
>
>> do I need to add something to it that takes the authorization? Or
>> will anything it does that uses admin files be allowed?
>
> Once you run something with AEWP(), it has root privileges.
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
>
>
>
-
On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
> I see. Then, how would you suggest to create a cloner/deleter, if it
> needs root privileges, but cannot use the security framework?
I didn't say you couldn't use the security framework. I said you ought
to consider re-thinking your strategy.
> And, since running scripts from root is dangerous, then is there any
> good way to be able to delete protected (not your user account)
> files? Or, should I just have it copy or delete files the user has
> access to?
There's nothing wrong with running scripts strictly as root, since a
lot of system scripts are run this way. But AEWP() doesn't run
executables as root; it runs them as the user with root privileges.
There's an important difference.
Instead of running a shell script, run another non-GUI command line
tool of your making with AEWP() that does the required privileged task
(s). Running shell code with root privileges as some user is possible,
but it's an easy attack vector due to the inheritance of the user's
shell environment. Running a command line tool is a bit more difficult
to hack (but still possible if someone is determined enough). Plus,
then you can use NSFileManager. :)
You could even take security to the extreme, as I once did in an
application, and check signatures before calling AEWP(), but that's
probably too extreme, as it's unlikely someone will rewrite or replace
your executable unless the file system gave them permission to do so.
Nick Zitzmann
<http://www.chronosnet.com/> -
On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:
>
> On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
>
>> I see. Then, how would you suggest to create a cloner/deleter, if
>> it needs root privileges, but cannot use the security framework?
>
> I didn't say you couldn't use the security framework. I said you
> ought to consider re-thinking your strategy.
>
>> And, since running scripts from root is dangerous, then is there
>> any good way to be able to delete protected (not your user account)
>> files? Or, should I just have it copy or delete files the user has
>> access to?
>
>
> There's nothing wrong with running scripts strictly as root, since a
> lot of system scripts are run this way. But AEWP() doesn't run
> executables as root; it runs them as the user with root privileges.
> There's an important difference.
>
> Instead of running a shell script, run another non-GUI command line
> tool of your making with AEWP() that does the required privileged
> task(s). Running shell code with root privileges as some user is
> possible, but it's an easy attack vector due to the inheritance of
> the user's shell environment. Running a command line tool is a bit
> more difficult to hack (but still possible if someone is determined
> enough). Plus, then you can use NSFileManager. :)
>
> You could even take security to the extreme, as I once did in an
> application, and check signatures before calling AEWP(), but that's
> probably too extreme, as it's unlikely someone will rewrite or
> replace your executable unless the file system gave them permission
> to do so.
Okay, I guess I should just put scheduling without needing the
password to the back of my queue.
I have one more question (sorry for all of these questions): If I call
AuthorizationCopyRights() every 280 (or anything less than 300 secs)
during the clone, will it keep the authorization alive (no need to
enter password again)?
Thanks for all your help–You have no idea how much it means to me :)
Cheers,
Joe Turner
>
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
>
>
>
-
On Thu, Jan 22, 2009 at 10:15 PM, Joe Turner <joeturner...> wrote:
>
> On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:
>
>>
>> On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
>>
>>> I see. Then, how would you suggest to create a cloner/deleter, if it
>>> needs root privileges, but cannot use the security framework?
>>
>> I didn't say you couldn't use the security framework. I said you ought to
>> consider re-thinking your strategy.
>>
>>> And, since running scripts from root is dangerous, then is there any good
>>> way to be able to delete protected (not your user account) files? Or, should
>>> I just have it copy or delete files the user has access to?
>>
>>
>> There's nothing wrong with running scripts strictly as root, since a lot
>> of system scripts are run this way. But AEWP() doesn't run executables as
>> root; it runs them as the user with root privileges. There's an important
>> difference.
>>
>> Instead of running a shell script, run another non-GUI command line tool
>> of your making with AEWP() that does the required privileged task(s).
>> Running shell code with root privileges as some user is possible, but it's
>> an easy attack vector due to the inheritance of the user's shell
>> environment. Running a command line tool is a bit more difficult to hack
>> (but still possible if someone is determined enough). Plus, then you can use
>> NSFileManager. :)
>>
>> You could even take security to the extreme, as I once did in an
>> application, and check signatures before calling AEWP(), but that's probably
>> too extreme, as it's unlikely someone will rewrite or replace your
>> executable unless the file system gave them permission to do so.
>
> Okay, I guess I should just put scheduling without needing the password to
> the back of my queue.
>
> I have one more question (sorry for all of these questions): If I call
> AuthorizationCopyRights() every 280 (or anything less than 300 secs) during
> the clone, will it keep the authorization alive (no need to enter password
> again)?
Don't do that. The standard way to accomplish a permanent unlock that
you're talking about is (I think) to have a suid root tool. You use
AEWP to run it as root so that it can become suid root, and after that
it simply *stays* suid root, as that's a filesystem property that
won't be disappearing spontaneously. As long as it's suid root you
don't need to touch AEWP again.
Of course you need to securely control access to your suid root tool
in that case, and I don't recall exactly how you do this, but I
believe the authorization APIs allow you to generate tokens that you
can pass to the tool to be checked for validity so that not just
anyone can come in and use the tool. And I'm pretty sure that Apple
has sample code to illustrate this. Definitely look at that sample
code no matter what; these APIs are ridiculously difficult to get
right, and you don't want to be working with them without a concrete
example sitting in front of you that you can crib from.
Mike -
On 23 Jan 2009, at 05:05, Michael Ash wrote:
> On Thu, Jan 22, 2009 at 10:15 PM, Joe Turner <joeturner...> wrote:Another source of info on this would be Dalrymple + Hillegass -
>>
>> On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:
>>
>>>
>>> On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
>>>
>>>> I see. Then, how would you suggest to create a cloner/deleter, if
>>>> it
>>>> needs root privileges, but cannot use the security framework?
>>>
>>> I didn't say you couldn't use the security framework. I said you
>>> ought to
>>> consider re-thinking your strategy.
>>>
>>>> And, since running scripts from root is dangerous, then is there
>>>> any good
>>>> way to be able to delete protected (not your user account) files?
>>>> Or, should
>>>> I just have it copy or delete files the user has access to?
>>>
>>>
>>> There's nothing wrong with running scripts strictly as root, since
>>> a lot
>>> of system scripts are run this way. But AEWP() doesn't run
>>> executables as
>>> root; it runs them as the user with root privileges. There's an
>>> important
>>> difference.
>>>
>>> Instead of running a shell script, run another non-GUI command
>>> line tool
>>> of your making with AEWP() that does the required privileged
>>> task(s).
>>> Running shell code with root privileges as some user is possible,
>>> but it's
>>> an easy attack vector due to the inheritance of the user's shell
>>> environment. Running a command line tool is a bit more difficult
>>> to hack
>>> (but still possible if someone is determined enough). Plus, then
>>> you can use
>>> NSFileManager. :)
>>>
>>> You could even take security to the extreme, as I once did in an
>>> application, and check signatures before calling AEWP(), but
>>> that's probably
>>> too extreme, as it's unlikely someone will rewrite or replace your
>>> executable unless the file system gave them permission to do so.
>>
>> Okay, I guess I should just put scheduling without needing the
>> password to
>> the back of my queue.
>>
>> I have one more question (sorry for all of these questions): If I
>> call
>> AuthorizationCopyRights() every 280 (or anything less than 300
>> secs) during
>> the clone, will it keep the authorization alive (no need to enter
>> password
>> again)?
>
> Don't do that. The standard way to accomplish a permanent unlock that
> you're talking about is (I think) to have a suid root tool. You use
> AEWP to run it as root so that it can become suid root, and after that
> it simply *stays* suid root, as that's a filesystem property that
> won't be disappearing spontaneously. As long as it's suid root you
> don't need to touch AEWP again.
>
> Of course you need to securely control access to your suid root tool
> in that case, and I don't recall exactly how you do this, but I
> believe the authorization APIs allow you to generate tokens that you
> can pass to the tool to be checked for validity so that not just
> anyone can come in and use the tool. And I'm pretty sure that Apple
> has sample code to illustrate this. Definitely look at that sample
> code no matter what; these APIs are ridiculously difficult to get
> right, and you don't want to be working with them without a concrete
> example sitting in front of you that you can crib from.
>
Advanced Mac OS X Programming.
It doesn't seem to be searchable on the web so you will need the
physical papery object.
Chapter 17 covers the whole SUID/ticket business in detail (21 pages )
with a working example.
> Mike
Jonathan Mitchell
Central Conscious Unit
http://www.mugginsoft.com -
Okay, so, it seems everyone was right :) I went to cocoabuilder to
find some of the responses to this, that I never got.
Anyways, it seems I can just call AEWP() once, and it should stay suid.
So, my last question to everyone is, how do I know if the tool is
suid. I mean, I could implement some sort of lock-unlock thing, and
then I would be pretty sure, but is there anyway to know for sure?
And, is there a way to take SUID away from it? So, if I want to lock
it, it would work.
Thanks everyone!
Cheers,
Joe Turner
On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:
>
> On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
>
>> I see. Then, how would you suggest to create a cloner/deleter, if
>> it needs root privileges, but cannot use the security framework?
>
> I didn't say you couldn't use the security framework. I said you
> ought to consider re-thinking your strategy.
>
>> And, since running scripts from root is dangerous, then is there
>> any good way to be able to delete protected (not your user account)
>> files? Or, should I just have it copy or delete files the user has
>> access to?
>
>
> There's nothing wrong with running scripts strictly as root, since a
> lot of system scripts are run this way. But AEWP() doesn't run
> executables as root; it runs them as the user with root privileges.
> There's an important difference.
>
> Instead of running a shell script, run another non-GUI command line
> tool of your making with AEWP() that does the required privileged
> task(s). Running shell code with root privileges as some user is
> possible, but it's an easy attack vector due to the inheritance of
> the user's shell environment. Running a command line tool is a bit
> more difficult to hack (but still possible if someone is determined
> enough). Plus, then you can use NSFileManager. :)
>
> You could even take security to the extreme, as I once did in an
> application, and check signatures before calling AEWP(), but that's
> probably too extreme, as it's unlikely someone will rewrite or
> replace your executable unless the file system gave them permission
> to do so.
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
>
>
>
-
On Fri, Jan 23, 2009 at 10:59 PM, Joe Turner <joeturner...> wrote:
> Okay, so, it seems everyone was right :) I went to cocoabuilder to find some
> of the responses to this, that I never got.
>
> Anyways, it seems I can just call AEWP() once, and it should stay suid.
>
> So, my last question to everyone is, how do I know if the tool is suid. I
> mean, I could implement some sort of lock-unlock thing, and then I would be
> pretty sure, but is there anyway to know for sure?
>
> And, is there a way to take SUID away from it? So, if I want to lock it, it
> would work.
"man 2 stat" to check the bit, "man 2 chmod" to set it.
Mike -
Cool, thanks!
Then I now have another question: Why not just run chmod on my utility
when it's 'unlocked', and change the userID to 0. Then when it's
locked, change it back to 501?
Or, is this exactly what AEWP() will do?
Thanks!
Cheers,
Joe Turner
On Jan 24, 2009, at 6:47 AM, Michael Ash wrote:
> On Fri, Jan 23, 2009 at 10:59 PM, Joe Turner <joeturner...> wrote:
>> Okay, so, it seems everyone was right :) I went to cocoabuilder to
>> find some
>> of the responses to this, that I never got.
>>
>> Anyways, it seems I can just call AEWP() once, and it should stay
>> suid.
>>
>> So, my last question to everyone is, how do I know if the tool is
>> suid. I
>> mean, I could implement some sort of lock-unlock thing, and then I
>> would be
>> pretty sure, but is there anyway to know for sure?
>>
>> And, is there a way to take SUID away from it? So, if I want to
>> lock it, it
>> would work.
>
> "man 2 stat" to check the bit, "man 2 chmod" to set it.
>
> Mike
-
I think I figured out how SD does it:
When you unlock SD!, it calls AEWP() on SDAgent. Then, SDAgent calls
setuid(0) to make itself root. With it as root, when it calls SDCopy,
or SDDiskTool, it calls it with AEWP, and since it's root, it doesn't
need the user's password to do this!
This is just my guess. But it sounds fairly right :)
Cheers,
Joe Turner
On Jan 24, 2009, at 6:47 AM, Michael Ash wrote:
> On Fri, Jan 23, 2009 at 10:59 PM, Joe Turner <joeturner...> wrote:
>> Okay, so, it seems everyone was right :) I went to cocoabuilder to
>> find some
>> of the responses to this, that I never got.
>>
>> Anyways, it seems I can just call AEWP() once, and it should stay
>> suid.
>>
>> So, my last question to everyone is, how do I know if the tool is
>> suid. I
>> mean, I could implement some sort of lock-unlock thing, and then I
>> would be
>> pretty sure, but is there anyway to know for sure?
>>
>> And, is there a way to take SUID away from it? So, if I want to
>> lock it, it
>> would work.
>
> "man 2 stat" to check the bit, "man 2 chmod" to set it.
>
> Mike
-
The proper way to construct everything you've described is discussed
in the Authorization Services Programming Guide.
Authorization Services Programming Guide
http://developer.apple.com/documentation/Security/Conceptual/authorization_
concepts/index.html
The current, most up-to-date and correct example of constructing an
application with a helper that performs privileged operations securely
on its behalf is "BetterAuthorizationSample" which replaces the
previous "MoreAuthSample" example code.
BetterAuthorizationSample
http://developer.apple.com/samplecode/BetterAuthorizationSample/index.html
It is critical to your users' security that you understand everything
presented in the above programming guide and example before you
attempt to write code that needs to run with elevated privileges. You
must not simply use AuthorizationExecuteWithPrivileges to run
arbitrary code or scripts "as root." You must install your helper
tool securely. There's a lot to do if you want to run code with
elevated privileges, and it must be done correctly; the rationale for
the design recommended by the Programming Guide and
BetterAuthorizationSample is documented in "Design and Implementation
Rationale.txt" within the example:
BetterAuthorizationSample - Design and Implementation Rationale
http://developer.apple.com/samplecode/BetterAuthorizationSample/listing4.ht
ml
Unfortunately, when it comes to system security there's no "I'm just…"
or "I simply want to…" All i's must be dotted and all t's crossed, or
you risk compromising your users' security. Fortunately there's
extensive documentation on how to manage the complexity involved, and
you can provide a decent user experience if you do the cooking by the
book.
-- Chris -
So, you are saying that I must create an install tool, that installs
my utility that will run as root?
On Jan 24, 2009, at 2:23 PM, Chris Hanson wrote:
> The proper way to construct everything you've described is discussed
> in the Authorization Services Programming Guide.
>
> Authorization Services Programming Guide
> http://developer.apple.com/documentation/Security/Conceptual/authorization_
concepts/index.html
>
> The current, most up-to-date and correct example of constructing an
> application with a helper that performs privileged operations
> securely on its behalf is "BetterAuthorizationSample" which replaces
> the previous "MoreAuthSample" example code.
>
> BetterAuthorizationSample
> http://developer.apple.com/samplecode/BetterAuthorizationSample/index.html
>
> It is critical to your users' security that you understand
> everything presented in the above programming guide and example
> before you attempt to write code that needs to run with elevated
> privileges. You must not simply use
> AuthorizationExecuteWithPrivileges to run arbitrary code or scripts
> "as root." You must install your helper tool securely. There's a
> lot to do if you want to run code with elevated privileges, and it
> must be done correctly; the rationale for the design recommended by
> the Programming Guide and BetterAuthorizationSample is documented in
> "Design and Implementation Rationale.txt" within the example:
>
> BetterAuthorizationSample - Design and Implementation Rationale
> http://developer.apple.com/samplecode/BetterAuthorizationSample/listing4.ht
ml
>
> Unfortunately, when it comes to system security there's no "I'm
> just…" or "I simply want to…" All i's must be dotted and all t's
> crossed, or you risk compromising your users' security. Fortunately
> there's extensive documentation on how to manage the complexity
> involved, and you can provide a decent user experience if you do the
> cooking by the book.
>
> -- Chris
>
-
On Jan 24, 2009, at 1:41 PM, Joe Turner wrote:
> So, you are saying that I must create an install tool, that installs
> my utility that will run as root?
I am saying that, in order to maintain your users' system security,
you must follow the guidance in the Authorization Services Programming
Guide and BetterAuthorizationSample example code when implementing
software that needs to run with elevated privileges.
Among other things, to be truly secure you must use a secure
installation mechanism. Do not write your own install tool — it can't
be made secure without itself being installed via a secure
installation mechanism. Instead, use Installer.app for your
installations since it's included with the operating system and not
modifiable with normal user privileges.
You can still ship your application as a drag-install; for example,
your application itself can include an installer package to do the
actual installation of the tool it uses and its launchd plist, and
open the package in Installer.app if the tool needs to be installed.
-- Chris -
On Sat, Jan 24, 2009 at 6:08 PM, Chris Hanson <cmh...> wrote:
> Among other things, to be truly secure you must use a secure installation
> mechanism. Do not write your own install tool — it can't be made secure
> without itself being installed via a secure installation mechanism.
> Instead, use Installer.app for your installations since it's included with
> the operating system and not modifiable with normal user privileges.
I'm afraid I don't understand this advice. Could you explain what sort
of vulnerability would exist in a custom install tool that would not
exist when using Installer.app to install a custom package?
Mike -
On Jan 24, 2009, at 6:29 PM, Michael Ash wrote:
> On Sat, Jan 24, 2009 at 6:08 PM, Chris Hanson <cmh...> wrote:
>> Among other things, to be truly secure you must use a secure
>> installation
>> mechanism. Do not write your own install tool — it can't be made
>> secure
>> without itself being installed via a secure installation mechanism.
>> Instead, use Installer.app for your installations since it's
>> included with
>> the operating system and not modifiable with normal user privileges.
>
> I'm afraid I don't understand this advice. Could you explain what sort
> of vulnerability would exist in a custom install tool that would not
> exist when using Installer.app to install a custom package?
Because Installer.app is installed by the operating system you can -
if you've taken appropriate security measures to begin with - be
reasonably certain that it hasn't been tampered with.
When writing your own install tool, you have a bootstrapping problem:
You will eventually need to have the user authorize some untrusted
code to run as root - code that could have been modified behind the
user's back.
An installer package could also have been writable by the user, but
modern packages can be signed so their integrity can be checked.
-- Chris -
But you can also code sign nowadays
On Jan 24, 2009, at 11:54 PM, Chris Hanson wrote:
> On Jan 24, 2009, at 6:29 PM, Michael Ash wrote:
>
>> On Sat, Jan 24, 2009 at 6:08 PM, Chris Hanson <cmh...> wrote:
>>> Among other things, to be truly secure you must use a secure
>>> installation
>>> mechanism. Do not write your own install tool — it can't be made
>>> secure
>>> without itself being installed via a secure installation mechanism.
>>> Instead, use Installer.app for your installations since it's
>>> included with
>>> the operating system and not modifiable with normal user privileges.
>>
>> I'm afraid I don't understand this advice. Could you explain what
>> sort
>> of vulnerability would exist in a custom install tool that would not
>> exist when using Installer.app to install a custom package?
>
> Because Installer.app is installed by the operating system you can -
> if you've taken appropriate security measures to begin with - be
> reasonably certain that it hasn't been tampered with.
>
> When writing your own install tool, you have a bootstrapping
> problem: You will eventually need to have the user authorize some
> untrusted code to run as root - code that could have been modified
> behind the user's back.
>
> An installer package could also have been writable by the user, but
> modern packages can be signed so their integrity can be checked.
>
> -- Chris
-
On Sat, Jan 24, 2009 at 9:29 PM, Michael Ash <michael.ash...> wrote:
> I'm afraid I don't understand this advice. Could you explain what sort
> of vulnerability would exist in a custom install tool that would not
> exist when using Installer.app to install a custom package?
It's vulnerable to a timing flaw. In order to securely install a
helper tool, the installation process must run as root. In order to
securely install an installer that runs as root, the installer
installer must run as root. In order to...
Installer.app solves this problem because it's preconfigured to be
secure. You can invoke it to do the privileged installation for you
without opening yourself up to the possibility that in between copying
the file and its later invocation that its contents have been changed.
--Kyle Sluder -
On Sun, Jan 25, 2009 at 12:54 AM, Chris Hanson <cmh...> wrote:
> On Jan 24, 2009, at 6:29 PM, Michael Ash wrote:
>
>> On Sat, Jan 24, 2009 at 6:08 PM, Chris Hanson <cmh...> wrote:
>>>
>>> Among other things, to be truly secure you must use a secure installation
>>> mechanism. Do not write your own install tool — it can't be made secure
>>> without itself being installed via a secure installation mechanism.
>>> Instead, use Installer.app for your installations since it's included
>>> with
>>> the operating system and not modifiable with normal user privileges.
>>
>> I'm afraid I don't understand this advice. Could you explain what sort
>> of vulnerability would exist in a custom install tool that would not
>> exist when using Installer.app to install a custom package?
>
> Because Installer.app is installed by the operating system you can - if
> you've taken appropriate security measures to begin with - be reasonably
> certain that it hasn't been tampered with.
>
> When writing your own install tool, you have a bootstrapping problem: You
> will eventually need to have the user authorize some untrusted code to run
> as root - code that could have been modified behind the user's back.
>
> An installer package could also have been writable by the user, but modern
> packages can be signed so their integrity can be checked.
So could a custom installer. It seems to me that the problem of
protecting a custom installer and the problem of protecting a custom
package being used with the system installer are equivalent. Is there
a way that a custom binary can be tampered with that a custom .pkg is
immune to?
Mike -
On Sun, Jan 25, 2009 at 3:19 AM, Kyle Sluder <kyle.sluder...> wrote:
> On Sat, Jan 24, 2009 at 9:29 PM, Michael Ash <michael.ash...> wrote:
>> I'm afraid I don't understand this advice. Could you explain what sort
>> of vulnerability would exist in a custom install tool that would not
>> exist when using Installer.app to install a custom package?
>
> It's vulnerable to a timing flaw. In order to securely install a
> helper tool, the installation process must run as root. In order to
> securely install an installer that runs as root, the installer
> installer must run as root. In order to...
>
> Installer.app solves this problem because it's preconfigured to be
> secure. You can invoke it to do the privileged installation for you
> without opening yourself up to the possibility that in between copying
> the file and its later invocation that its contents have been changed.
Instead of opening yourself up to the possibility that the contents of
the installer binary have been changed, you open yourself up to the
possibility that the contents of the installer .pkg have been changed.
Doesn't seem any better to me.
Mike
