Why does this admin authorization which is not root authorization let the installer run scripts as root, as Adam proved by a test package? Isn’t that a serious bug and security hole, as he claims?
Well, yes and no. The answer lies in a file called /etc/authorization. This is an XML file in property list format which defines the various rights a process can ask for when using the Authorization Framework, and defines a set of rules that are applied when this happens.
“Rainer Brockerhoff”:http://brockerhoff.net/bb/viewtopic.php?p=1973

Well, yes, but there’s a problem with that. As I noted in the article, I altered the /etc/authorization file to try and change the behavior and it did not change it. In fact, the authorization file says the user should be prompted and the user still isn’t. Installer is doing something inside itself to get around that, and that’s the problem. Apple actively went against their own security practices to make the product easier on novices at the expense of security, a very Microsoftian practice.

Translating this into a slightly less geeky form, this is the autorization right requested by the AuthorizationExecuteWithPrivileges() call, which is the one used by the Installer. It can be granted to users of the “admin” group, is granted automatically to the root user, and times out in 5 minutes. AuthorizationExecuteWithPrivileges(), in turn, is the system call to run a script as root; which is allowed for administrators, as we’ve seen.
“Rainer Brockerhoff”:http://brockerhoff.net/bb/viewtopic.php?p=1973

I don’t believe they’re even calling that function to gain root, honestly, because it follows the authorization file. It can’t not. They’re doing something else and I believe that’s a red herring here. There’s no way to call that function and have it not consult the database, so they’re doing something internal to get around it. Be that a SUID program somewhere or some private call, they’re getting around the clause in authorization that says the user needs a password.

That’s my greater beef with this. While on the one hand you have the major issue of being elevated to root status without a password and running external scripts as root without notification (and the Installer doesn’t let you see what’s being installed ahead of time, another issue with the thing), on the other hand you have the existence of a private call that allows an admin user to become root without a password. However they’re doing it, someone can figure it out and then do it in other software.

That is the truly scary part about this, and the part I didn’t want to talk about in the wide release. Apple’s hacked their own OS and any competent disassembler child can go in and see how and recreate it.