Note: This post is in english because it’s related to the Google Summer of Code.
Now in the early stages of my gsoc project I looked at how user authorization is handled by OS X. The owner-permissions model of the underlying UNIX system is not so flexible when it comes to a desktop system because permissions are bound to files and there’s no method to tell the system what a user can do instead of which files it can read/write. Another problem is that in order to do administrative tasks, a program has to be run as root, with all the risks that this involves.
For this reason Mac OS X implements a policy-based authorization system. Every time that an application needs to do something that require privileges, it will ask for them to the system, which will decide if grant the privileges or not. This decision will be based on a policy database which the system administrator can edit to tune the system’s security policies.
The APIs used by the applications to access those features are included in the Security.framework system package, and are called Authorization Services. Using this API, an application can ask the system if it has the authorization to do something. The Security Server will look at the authorization database and could ask the user to authenticate. For example if the rule set for a specific right is “authenticate-admin”, the user will be asked for a username and password of an administrator.
But now that the application know that it can, for example, write to a system file, how can it actually write it? It’s still a process running as a simple user and for a unix process there’s no way to change it’s uid if it’s not already root. For this reason, the application needs to call an external binary which has to be run as root and will do the job. This approach is called “caller/helper” and its very common on many systems. The last missing piece is: how to launch a process with high privileges? Child processes inherits the uid from the parent, so a simple fork() won’t work. In Mac OS X 10.3 and earlier, apple suggested for this purpose the use of the setuid binary. An executable file owned by root, with the setuid bit will run as the owner. This approach had many security risks related to the setuid bit and is now deprecated. The new solution, introduced in OS X 10.4, is the Launch Daemon. Using it, you can launch a process with root privileges that will (if authorized) do the restricted operation.
The example included is a trivial text editor that can open and save files of other users. You can find the source code here:
Link to the example source code
A step-by-step comment of the code follows.
Apple & Macintosh, Objective-C