Re: Problem within a MoreSecurity helper tool
Re: Problem within a MoreSecurity helper tool
- Subject: Re: Problem within a MoreSecurity helper tool
- From: John Andersson <email@hidden>
- Date: Thu, 22 Apr 2004 22:32:26 +0200
OK! Thanks for the hints.
I now use fork() and execl() to run the other installer.
I still get the -108 error though. Please observe that the error is
returned by the "MoreSecExecuteRequestInHelperTool();" function, not by
the helper tool!
(Both the helpertool's "main" and "SetupToolCommandProc" returns noErr)
If execl (in the child process) fails due to a wrong path or something,
and I exit with "exit();" I don't get the error. Only if execl()
works...! :-)
I'm not desperate to solve it, because everything seem to work fine
except the error being returned.
Brg
/John
2004-04-22 kl. 18.50 skrev Quinn:
At 15:20 +0200 22/4/04, John Andersson wrote:
Any clues? It doesn't feel quite OK to just ignore the memory error.
Or is it not a memory error? :-)
It's almost certainly not a memory error (-: The most likely cause
for this problem is that MoreSecurity specifically goes out of its way
to destroy any state that it inherits from the parent process
(MoreSecDestroyInheritedEnvironment). The goal of this is to prevent
these implicit parameters from adversely affecting security. However,
destroying the environment often has unexpected side effects (-:
My guess is that "system" is dependent on something in the environment
(the PATH variable, or the SHELL variable, or something like that),
which is destroyed by MoreSecurity, and thus it fails.
You could fix this by working out exactly what the root cause is and
establishing an appropriate default.
However, and this as a big HOWEVER, you should not do this. Calling
"system" from a privileged process is a *really* *bad* *idea*,
security-wise. This is for exactly the reasons I've outlined above.
"system" takes a whole pile of implicit parameters, and it's very easy
for an attacker to set up those implicit parameters to break security.
An excellent example is the "IFS" environment variable. If you search
on the web for "IFS setuid" you'll find some cool examples of this.
A much better approach is to explicitly "fork" and then "exec" the
tool that you want to run.
The same applies for "popen", btw. Neither "system" nor "popen"
should be called by privileged processes. If I had my way I'd make
them check the UID and fail if it's zero (-:
S+E
--
Quinn "The Eskimo!"
<http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications,
Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.