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:
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
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.
to post comments)