Re: Security framework refuses to work at all
Re: Security framework refuses to work at all
- Subject: Re: Security framework refuses to work at all
- From: Finlay Dobbie <email@hidden>
- Date: Fri, 25 Oct 2002 13:58:54 +0100
On Friday, October 25, 2002, at 01:40 pm, Stiphane Sudre wrote:
From what I can quickly read in this documentation (which is buggy as
the link:
http://developer.apple.com/techpubs/macosx/CoreTechnologies/
securityservices/authservices.html does not exist), I don't see
anything done that is strictly not recommended by the documentation.
I don't know where you got that link from, but here the
CoreTechnologies overview page correctly points to
<
http://developer.apple.com/techpubs/macosx/CoreTechnologies/
securityservices/authorizationservices/authservices.html>, from which
you can get to
<
http://developer.apple.com/techpubs/macosx/CoreTechnologies/
securityservices/authorizationservices/authorization_concepts/
index.html>. I quote:
----
Some privileged operations require special permissions. For example, an
application that restarts the Internet daemon must have root
privileges. There are three possible ways to perform this operation,
all with their own problems:
Make the application run as root by calling itself with a special
Authorization Services function.
Set the setuid bit of the application and change its owner to root
and use the special Authorization Services function.
Factor out the operation that performs the privileged operation and
put it in a separate setuid toola tool that has its setuid bit setand
set the setuid tool's owner to root.
Both the first and second options are a security breach waiting to
happen. When the privileged application runs, it calls a special
function that Authorization Services
providesAuthorizationExecuteWithPrivileges (see "Calling a Helper Tool
as Root" for more details). Calling this function executes any
application or tool with root privileges, regardless of the owner of
the application or tool. This is very dangerous since parts of the
application can be easily replaced.
The second option is to set the setuid bit of the privileged
application and change its owner to root. The setuid bit, when set,
allows the process running it to masquerade as another user. Setting
the setuid bit and owner of the application to a different user, such
as root, makes it more difficult to replace. However, running code as
root is very dangerous and should be done as seldom as possible.
Setting the setuid bit on an entire application is especially dangerous
because you are trusting that your entire application, and the code
your application links to, is free of security holes.
The third scenario is by far the best. The application is split into an
application that controls all of the graphical user interface elements
and nonprivileged operations, and a helper tool that performs only the
operations involved in restarting the Internet daemon. The helper
tool's setuid bit is set and the owner is set to root. The proper
Authorization Services functions are used as described previously.
Factoring and setting the setuid bit not only minimizes the risk but
also makes it easier to audit your code for security holes.
----
And, quoting from the Authorization Services Reference for
AuthorizationExecuteWithPrivileges at
<
http://developer.apple.com/techpubs/macosx/CoreTechnologies/
securityservices/authorizationservices/authorization_ref/index.html>:
----
Special Considerations
You should use this function only to allow installers to run as root
and to allow a setuid tool to repair its setuid bit if lost. This
function works only if the Security Server establishes proper
authorization.
This function poses a security concern because it will indiscriminately
run any tool or application, severely increasing the security risk. You
should avoid the use of this function if possible. One alternative is
to split your code into two partsthe application and a setuid tool.
The application invokes the setuid tool using standard methods. The
setuid tool can then perform the privileged operations. If the tool
loses its setuid bit, use the AuthorizationExecuteWithPrivileges
function to repair it. Factoring your program minimizes the use of this
function and reduces the risk of harm. Read Inside Mac OS X: Performing
Privileged Operations With Authorization Services.
----
So, I'm not sure exactly what you meant when you said you can't see
where Apple recommends you don't use it. Unless, of course, you are an
installer.
-- Finlay
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.