We’re used to think of system-enforced access policies as crude and coarse-grained, such as the setuid permission bit that lets a user execute a program as the file’s owner. Fine-grained access has to be enforced by individual applications, a laborious coding process that is weakened by not being able to take advantage of underlying operation system security. PolicyKit, developed by Red Hat and included in Fedora 8, ameliorates this unsatisfactory situation.
Red Hat developer David Zeuthen describes through examples the types of access problems solved by PolicyKit: “it’s fine to mount removable media; it’s not fine to mount fixed media; it’s not fine to change the timezone.” These are operating system capabilities that can be enforced by such operating system components as the HAL or the filesystem. But any application can use PolicyKit API to enforce any kind of access it chooses to, and it gets the backing of the operating system. Zeuthen compares PolicyKit to Authorization Services on Mac OS X and Group Policy in Windows.
More justifications for PolicyKit were sent to me by Zeuthen in email (lightly edited here):
Many authorization systems, such as Solaris’s RBAC (Role Base Access Control), are static in the sense that the system administrator decides what authorizations you have. If you don’t have the authorization, the game’s over; you typically need to send mail to the administrator. This is annoying for many users.
PolicyKit provides the ability for an unauthorized user to gain authorization by authenticating at the time of issuing the access request. This is useful in two types of situations:
To check that it’s a human being that started an operation; this is useful, for instance, for dial-up software. Say you installed some new software that contains virus/malware (common on Windows). The malware now uses the NetworkManager API to dial the modem to a premium number in a foreign country. With PolicyKit, NetworkManager will ask the user to authenticate before dialing an untrusted number.
To check whether the human being who started an operation is an administrator. This is useful, for instance, in kiosk, library, home and some enterprise settings where the users are essentially untrusted. You don’t want them to mess around with reconfiguring the system and you want to give them minimal permissions. On the other hand, the admin should be allowed access easily through the UI.
Notably, Mac OS X already provides these two features with Authorization Services.
PolicyKit is simply a layer on top of long-existing parts of Unix and Linux. On Linux, it uses D-Bus to exchange messages (so that applications can reach standard parts of the system such as the filesystem) and queries security layers such as PAM for authentication. It also contains a cache to speed up repeated requests to resources. All these things are neatly tucked away behind the API so that the application programmer doesn’t have to worry about them; this also makes programs more portable. Zeuthen is also offering an API for GNOME applications.
Zeuthen pointed out that by themselves, the HAL/D-Bus/NetworkManager combination have the same problems as setuid; they have trouble telling who has issued a request. Therefore, he says, “in Fedora and SUSE, HAL and NetworkManager reject requests from users not on the local system console (e.g. not in front of the computer). On Debian and Ubuntu, they reject requests unless the user is in a special UNIX group (e.g. the plugdev group).”
One of the benefits PolicyKit offers system administrators is giving them a single, centralized location to he can edit authorization information for users. Zeuthen is talking to the developers of the FreeIPA project (who, like Zeuthen, work at Red Hat) to centralize policy information in one place on the network, such as a directory server.
PolicyKit recognizes users and the objects they want to manipulate through a three-part classification (Subject, Action, Object) that is familiar throughout the security field, whether in the Unix “who-permissions-object” model (”group X has write permission to file Y”) or SELinux’s “role-access-target” model.
Zeuthen tells me that PolicyKit has only a few uses in Fedora 8, but will really blossom in Fedora 9. Some of its uses there will include:
- Replacing the usermode/consolehelper setup
- The PackageKit installation/upgrade tool
- gnome-system-monitor
- gnome-power-manager
- A “Manage Authorizations” capplet
- A new clock applet
It doesn't seem as if PolicyKit will replace SELinux or PAM? If that's right, you still don't have a single policy DB. So why would an SA want yet another policy DB to maintain?
On the other hand, if PolicyKit is meant to replace SELinux it won't be good enough as described to pass C2 or Common Criteria for trusted base system components. Or, if meant to replace PAM it should become the new PAM and not a layer on top of PAM (which requires both PolicyKit and PAM security configuration files to be maintained.)
What am I missing?
SELinux serves a different purpose from PolicyKit. SELinux is a mandatory access control solution to contain processes and to prevent them from executing particular actions. PolicyKit is a toolkit to delegate parts of system administration. SELinux can't do what PolicyKit does. PolicyKit cannot do what SELinux does. They, therefore, are independent and complementary.