[starman]

Hi all,
I'm just trying to determine the answer to this simple question. If I want to run an unprivilaged task, NSTask is OK, but if I need to run something that requires sudo in front of it, I need AuthorizationExecuteWithPrivileges and ONLY that? NSTask can't do privilaged commands? Also, is there sample code that shows privilaged task output redirected to a window like the Moriarty sample project? I can't find that anywhere. Thanks.

Mike

[fitter]

Take a look at this:

http://developer.apple.com/samplecod...AuthSample.htm

It represents Apple's best authorized code sample to date. It's still a little confusing, especially the useless typedefs, and the MoreUnix.c code should just be integrated with other portions of the code to make the flow clearer, but the comments do a decent job of explaining what's going on.

In short, don't use AEWP: it's buggy, and will execute anything as root. Effectively, it punches a hole in the security architecture. It was initially created, as I understand it, for certain developers to run their installers with elevated privileges (VISE installers, for example). The pipe you get with it doesn't return things written to stderr, you don't get a pid for the process you execute, and it poses a potential security risk.

The author talks of checking the the hash of the tool the code will execute, to verify that the tool is the right one, but he points out correctly that prebinding effectively makes this check worthless.

[starman]

Thanks for the link, and yes, the code's pretty obfuscated. There's SO much going on there compared to the very simple AuthSample I found. The AuthSample's like 20 or so lines and just executes the CLI command I want and writes it to stdout/err (although I want to redirect it to a pipe). Now I just have to tackle the design and I should be able to get this app done.

Mike

[altimac]

does apple itself advice not to use AEWP ?
i suppose not, but what do you use fitter ?

thanks

[Angus_D]

Originally posted by altimac:
does apple itself advice not to use AEWP ?

Yes.

i suppose not, but what do you use fitter ?

A self-restricted, self-repairing setuid root tool.

[absmiths]

Originally posted by Angus_D:
Yes.A self-restricted, self-repairing setuid root tool.

Wait a minute, that doesn't sound good. You actually change the setuid bit of the executable? I can't imagine that being secure.

[Angus_D]

Originally posted by absmiths:
Wait a minute, that doesn't sound good. You actually change the setuid bit of the executable? I can't imagine that being secure.

Well you obviously haven't looked at the documentation on the Security framework. You factor out your privileged code into a tool, and use Authorization Services to check you are allowed to do things. If you don't pass a valid auth ref to the tool, it won't do anything. If you're not root, you can't change the tool to not want a valid ref. Therefore, it's secure.

[macmike42]

Originally posted by Angus_D:
Well you obviously haven't looked at the documentation on the Security framework. You factor out your privileged code into a tool, and use Authorization Services to check you are allowed to do things. If you don't pass a valid auth ref to the tool, it won't do anything. If you're not root, you can't change the tool to not want a valid ref. Therefore, it's secure.

You forgot to mention that when the tool is compiled, an md5 checksum is automatically generated for it so that your non-privileged code will refuse to execute your privileged tool (or "repair" it to make it setuid root) if the internally stored checksum doesn't match. It's actually extremely secure, and nearly hassle-free for the end user.

[Angus_D]

Originally posted by macmike42:
You forgot to mention that when the tool is compiled, an md5 checksum is automatically generated for it so that your non-privileged code will refuse to execute your privileged tool (or "repair" it to make it setuid root) if the internally stored checksum doesn't match.

Oh yes, so I did. Silly me -especially considering I do this in my own code

[fitter]

But the MD5 of any binary on OS X is currently unreliable, because prebinding can change the checksum out from under you. The author of the sample I posted above makes note of this in the comments. I've been bugging Apple to ditch prebinding, since it makes OS X unusable as an enterprise server: no admin is going to consider any operating system that changes *binaries*, for god's sake: there's no way to tell the difference between, say, a hacked ps and one that's simply been re-prebound.