Centralizing policy rules with PolicyKit

Linux security policy is very simple at its core: the root user can do anything, while all other users can do very little. Unfortunately, administrators want to be able to allow other users to do a limited subset of the things root is permitted to do. Various solutions have been implemented to try and solve this problem, with a recent one being PolicyKit.

Mounting removable filesystems, CDs, USB devices, and the like, is a classic example of a root-only task that some non-privileged users might be allowed to perform. In the past, various mechanisms using groups or mount options in /etc/fstab have been used with some success, but the mechanisms were specific to mounting and did not provide the flexibility that some administrators would like. Network configuration - particularly for wireless networking - is another common task that users might be allowed to do.

PolicyKit is an attempt to centralize these kinds of decisions into a single policy file that the administrator can use to set the kinds of access regular users should be allowed. Previous solutions required changing each utility to handle policy, each in its own unique format and file(s). PolicyKit is meant to avoid all of that, creating a single place, with a consistent syntax (the now ubiquitous XML), that details the policy rules for that system.

The PolicyKit philosophy decouples the "mechanism" of performing the privileged operation from the user interface used to request it. A GUI network configuration tool might allow a user to choose a different network to associate with, but would have no direct means to make that change. It would, instead, contact a privileged network management daemon through an interprocess communication mechanism (such as D-Bus). That daemon would use the PolicyKit API to determine whether to grant the request.

In order to make that decision, PolicyKit needs three pieces of information, the subject, object, and action. The subject is the user and process requesting the action, while the object is what entity the action is being requested on. In a network configuration example, the subject would be a uid, along with additional identifying information such as SELinux security context, the action would be to change the association, and the object would be the network device.

The mechanism code calls the PolicyKit library, passing the subject, object, and action, receiving back a decision. The decision could be a simple yes or no, or it could, instead, require that the user authenticate - either as themselves or as root - before allowing the operation. Re-authentication can be required on sensitive actions, such as those that malware or malicious users might want to perform, to provide an additional layer of security. All of this policy is governed by the entries in the PolicyKit configuration file. Once the decision has been rendered, it is up to the mechanism to enforce it. This may require coordination with the UI, especially if authentication is required.

Administrators can modify the PolicyKit configuration by way of an XML file, usually PolicyKit.conf. The man page gives a few examples of entries like the following:

    <match action="org.freedesktop.hal.storage.mount-fixed">
      <match user="davidz">
        <return result="yes"/>
      </match>
      <match user="freddy">
        <return result="no"/>
      </match>
    </match>

As should be relatively easy to see, this configuration would allow the user "davidz" to perform the action "mount-fixed" while disallowing the user "freddy". Depending on the default value for that action, as specified in the mechanism's configuration, users not listed could be denied, allowed, or be required to authenticate.

Configuration for mechanisms, which lists the supported actions along with a default policy, is specified in a separate XML file. The mechanism could generate the file on startup and remove it on exit, completely removing the action from the system when it is inactive. Action configuration also includes the message strings that will be displayed by the UI when authenticating or denying users.

PolicyKit has been added to Fedora 8, but is, as yet, mostly unused. There are plans to integrate various GNOME configuration tools with PolicyKit for Fedora 9 and a GNOME API has been created to assist with that. One would guess that a KDE API is in the wings as well.

PolicyKit is not meant to replace SELinux or other security mechanisms, it is simply a means to allow users more privileges in a centralized, easily audited, way. PolicyKit works within the existing access control framework, using whatever privileges have been given to the mechanism. In the end, PolicyKit just provides advice to another program, it is up to that program to enforce the decision, while the OS can and does enforce its own rules upon that process.

---

(Log in to post comments)

It seems to me that Polykit is a way to reduce exposure of privilaged applications to
non-privilaged users. This should go a long way to reducing the amount of root-level exploits
going on in a typical Linux desktop. 

Say you have (a classic example) cdrecord (or wodim or whatever people use nowadays) set to
run with root rights for a paticular group of users. Well that's a non-trivial program and
it's going to be ripe for abuse if a account gets comprimised. Essentially your giving people
rights to at least part of the in-kernel SCSI stuff. 

Another example is the Ubuntu desktop were you have a large number of applications that
require gksudo to work properly. Your giving root rights to  many large and complex GUI
programs with a whole host of dependancies and many many different code paths that little to
nothing to do with.. say.. updating the machine with latest security fixes, which is a
required thing to do and not easy for admins to do for users travelling around with laptops.

So PolicyKit, it seems to me, will reduce the exposure of these privilaged activities down to
the dbus system and the input of whatever daemon you have floating around to take care of the
request.  I figure that as long as you have strong input validation and dbus was designed
correctly then it should be a much better system for Linux desktop rather then the sudo/setgid
stuff.

openSUSE shipped PolicyKit before Fedora 8 came out, but they don't seem to have made a huge
fuss about it.

That would be because it's got the "not-written-here" syndrom. David is the main developer,
and he works for Red Hat.

Making security decisions with an XML parser?

Why..? Why? Oh, the beauty and conciseness and easy to edit with lots of descriptive comments,
that must be it.