Re: Security framework refuses to work at all

FROM : Kelly K
DATE : Fri Oct 25 23:56:49 2002

On Friday, October 25, 2002, at 12:41 PM, <email_removed> wrote:

>
> On vendredi, octobre 25, 2002, at 08:12  PM, Kelly K wrote:
>
>> On Friday, October 25, 2002, at 06:17 AM, Stiphane Sudre wrote:
>>>> [...]
>>>> 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.
>>>
>>> This is the line I don't agree with. It will not run any tool, it
>>> will run the tool I set in the path as stated by the documentation:
>>>
>>> "This function enables you to execute the tool you specify in the
>>> pathToTool parameter as a separate, privileged process."
>>>
>>
>> Yes, until someone replaces the tool you call with my EvilTool [tm
>> patent pending].  AEWP will call any tool, regardless of the
>> privileges set on that tool. So now your app calls my EvilTool  with
>> root privileges.  While this may not be an issue with mv, or tools
>> with certain permissions sets, it is definitely a problem if
>> permissions allow the tool to be easily replaced.
>
>
> I might be missing something obvious but I don't see what the
> difference is between:
>
> - Application A running 'mv' via the Security Framework
> - Application A running Application B via Security Framework and
> Application B running 'mv'
>
> In both cases, your EvilTool is going to run with the root privileges.
>

There is no difference between your two examples.

All I am trying to point out is that AEWP does not perform any checks
to make sure that you are calling the correct tool.  That is why the
documentation says that AEWP will "indiscriminately run any tool or
application".  Replacing the tool is one possible security threat,
another is replacing the pathname in the AEWP call.  Care needs to be
taken when using this function to avoid these situations.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.