Chapter 9. PolicyKit

Contents

9.1. Available Policies and Supported Applications
9.2. Authorization Types
9.3. Modifying and Setting Privileges
9.4. For more information

Abstract

PolicyKit is an application framework that acts as a negotiator between the unprivileged user session and the privileged system context. Whenever a process from the user session tries to carry out an action in the system context, PolicyKit is queried. Based on its configuration—specified in a so-called policy—the answer could be yes, no, or authentication needed. Unlike classical privilege authorization programs such as sudo, PolicyKit does not grant root permissions to an entire process, following the least privilege concept.

[Note]Two PolicyKit Versions in Parallel

At the moment, there are two PolicyKit versions available with openSUSE in parallel: the old PolicyKit and the new polkit version (polkit-1), which is a re-write of the old PolicyKit version. The following sections are basically documentation on the old PolicyKit version.

9.1. Available Policies and Supported Applications

At the moment, not all applications requiring privileges make use of PolicyKit. In the following the most important policies available on openSUSE® are listed.

PulseAudio
Set scheduling priorities for the PulseAudio daemon
smpppd
Controlling dial-up connections
CUPS
Add, remove, edit, enable or disable printers
Backup Manager
Modify schedule
GNOME
Modify system and mandatory values with GConf
Change the system time
libvirt
Manage and modify local virtualized systems
NetworkManager
Apply and modify connections
PolicyKit
Read and change privileges for other users
Modify defaults
PackageKit
Update and remove packages
Refresh repositories
System
Wake on LAN
Mount or unmount fixed, hotpluggable and encrypted devices
Eject and decrypt removable media
Enable or disable WLAN
Enable or disable Bluetooth
Device access
Stop, suspend, hibernate and restart the system
Undock a docking station
YaST
Register product
Change the system time and language

9.2. Authorization Types

Every time a PolicyKit-enabled process carries out a privileged operation, PolicyKit is asked whether this process is entitled to do so. The answer PolicyKit gives depends on the policy defined for this process. It can be yes, no, or authentication needed. By default, a policy contains implicit privileges, which automatically apply to all users. It is also possible to specify explicit privileges which apply to a specific user.

9.2.1. Implicit Privileges

Implicit privileges can be defined for any, active, and inactive sessions. An active session is the one in which you are currently working. It becomes inactive when you switch to another console for example. When setting implicit privileges to no, no user is authorized, whereas yes authorizes all users. However, in most cases it is useful to demand authentication.

A user can either authorize by authenticating as root or by authenticating as self. Both authentication methods exist in four variants:

Authentication

The user always has to authenticate

One Shot Authentication

The authentication is bound to the instance of the program currently running. Once the program is restarted, the user is required to authenticate again.

Keep Session Authentication

The authentication dialog box offers a check button Remember authorization for this session. If checked, the authentication is valid until the user logs out.

Keep Indefinitely Authentication

The authentication dialog box offers a check button Remember authorization. If checked, the user has to authenticate only once.

9.2.2. Explicit Privileges

Explicit privileges can be granted to specific users. They can either be granted without limitations, or, when using constraints, limited to an active session and/or a local console.

It is not only possible to grant privileges to a user, a user can also be blocked. Blocked users will not be able to carry out an action requiring authorization, even though the default implicit policy allows authorization by authentication.

9.3. Modifying and Setting Privileges

To modify implicit privileges or to set explicit ones, you can either use the graphical System Policies tool available in the Advanced tab of the KDE System Settings, use the command line tools shipped with PolicyKit, or modify the configuration files. While the GUI and the command line tools are a good solution for making temporary changes, editing the configuration files should be the preferred way to make permanent changes.

[Note]The graphical GNOME Authorizations tool

The graphical Authorizations tool available with GNOME is for the old PolicyKit. Better use the above mentioned tools.

9.3.1. Using the Command Line Tools

At the moment, there are two PolicyKit versions available in parallel with openSUSE: the old PolicyKit and the new polkit version (polkit-1), which is a re-write of the old PolicyKit version.

9.3.1.1. PolicyKit

PolicyKit (PolicyKit) comes with two command line tools for changing implicit privileges and for assigning explicit privileges. Each existing policy has got a speaking, unique name with which it can be identified and which is used with the command line tools. List all available policies with the command polkit-action.

polkit-action

List and modify implicit privileges. Using this command you can also reset all policies to the default value. When invoked with no parameters, the command polkit-action shows a list of all policies. See man 1 polkit-action for more information.

polkit-auth

Inspect, grant, block and revoke explicit privileges. To print a list of explicit privileges for a specific user, use the command polkit-auth --explicit-detail --user USER where USER has to be replaced by a valid username. If the --user option is left out, privileges for the user executing the command are shown. See man 1 polkit-auth for more information.

[Note]Restrictions of polkit-action on openSUSE

Using the option --show-overrides, polkit-action lists all policies that differ from the default values. With --reset-defaults action one can reset the privileges for a given action to the defaults. However, polkit-action always operates on the upstream defaults, so it is not possible to list or restore the defaults shipped with openSUSE. Refer to Section 9.3.3, “Restoring the Default Privileges” for further information.

Section 9.3.2, “Modifying Configuration Files” and Section 9.3.3, “Restoring the Default Privileges” apply for the old PolicyKit only.

9.3.1.2. polkit

For more information about polkit, see http://hal.freedesktop.org/docs/polkit/.

9.3.2. Modifying Configuration Files

Adjusting privileges by modifying configuration files is useful when you want to deploy the same set of policies to different machines, for example to the computers of a specific team. It is possible to change implicit as well as explicit privileges by modifying configuration files.

9.3.2.1. Modifying Configuration Files for Implicit Privileges

openSUSE ships with two sets of default authorizations located in /etc/polkit-default-privs.standard and /etc/polkit-default-privs.restrictive. The .standard file defines privileges suitable for most desktop systems. It is active by default. The .restrictive set of privileges is designed for machines administrated centrally. Activate it by setting POLKIT_DEFAULT_PRIVS to restrictive in /etc/sysconfig/security and run set_polkit_default_privs as root afterwards. Do not modify these two files.

In order to define your custom set of privileges, use /etc/polkit-default-privs.local. Privileges defined here will always take precedence over the ones defined in the other configuration files. To define a privilege, add a line for each policy with the following format:

privilege_name any_session:inactive_session:active_session

For a list of all privilege names available, run the command polkit-action. The following values are valid for the session parameters:

yes

grant privilege

no

block

auth_self

user needs to authenticate with own password every time the privilege is requested

auth_self_keep_session

user needs to authenticate with own password once per session, privilege is granted for the whole session

auth_self_keep_always

user needs to authenticate with own password once, privilege is granted for the current and for future sessions

auth_admin

user needs to authenticate with root password every time the privilege is requested

auth_admin_keep_session

user needs to authenticate with root password once per session, privilege is granted for the whole session

auth_admin_keep_always

user needs to authenticate with root password once, privilege is granted for the current and for future sessions

Run set_polkit_default_privs to activate your settings.

9.3.2.2. Modifying Configuration Files for Explicit Privileges

Explicit privileges can be set in /etc/PolicyKit/PolicyKit.conf. This configuration file is written in XML using the PolicyKit DTD. The file that is shipped with openSUSE already contains the necessary headers and the root element <config>. Place your edits inside the <config> tags.

match

Specify an action or a user. match knows two attributes, user and action, but only a single attribute is allowed. Use nested match statements to combine attributes. POSIX Extended Regular Expressions are allowed as attribute values.

user=USER

Specify one or more login names. Separate multiple names by the | symbol.

action=policy

Specify a policy by it's unique identifier. To get a list of all available policy identifiers use the command polkit-action.

return

Specify the answer PolicyKit will return. Takes a single attribute, result=value with one of the values listed under Section 9.3.2.1, “Modifying Configuration Files for Implicit Privileges”.

define_admin_auth

Specify users or groups allowed to authorize with their own password where normally the root password would be required. Takes the attributes user=USER or group=GROUP, but only one may be used at a time. Multiple attribute values must be separated by |, Extended POSIX Regular Expressions are not supported. Applies to all policies when used at the top level, or to specific policies when used within <match> statements.

Example 9.1. An example /etc/PolicyKit/PolicyKit.conf file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN"
"http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd">1
<config version="0.1">2
  <match action="org.freedesktop.packagekit.system-update">3
    <match user="tux">
      <return result="yes"/>
    </match>
  </match>
  <match action="org.freedesktop.policykit.*">4
    <match user="tux|wilber">
      <return result="no"/>
    </match>
  </match>
  <define_admin_auth group="administrators"/>5
</config>

1

The first three lines of the config file are the XML header. These lines are already present in the template file, leave them untouched.

2

The XML root element must always be present. The attribute version is mandatory, currently the only valid value is 0.1. Already present in the template file.

3

A statement granting the user tux the privilege to update packages via PackageKit without having to authorize.

4

Withdraw privileges for all PolicyKit related policies from the users tux and wilber.

5

This statement allows all members of the group administrators to authenticate with their own password whenever authentication with the root password would be required. Since this statement is not nested within constraining match statements, it applies to all policies.


9.3.3. Restoring the Default Privileges

Each application supporting PolicyKit comes with a default set of implicit policies defined by the application's developers, the so-called upstream defaults. The privileges defined by the upstream defaults are not necessarily the ones that are activated by default on openSUSE. openSUSE comes with a predefined set of privileges (see Section 9.3.2.1, “Modifying Configuration Files for Implicit Privileges” for more information) that is activated by default, overriding the upstream defaults.

Since the Authorization tool and the PolicyKit command line utilities always operate on the upstream defaults, openSUSE comes with the command-line tool set_polkit_default_privs that resets privileges to the values defined in /etc/polkit-default-privs.*. However, set_polkit_default_privs will only reset policies that are set to the upstream defaults. To reset all policies to the upstream defaults first and then apply the openSUSE defaults, run the following command:

rm -f /var/lib/PolicyKit-public/* && set_polkit_default_privs
[Important]/etc/polkit-default-privs.local

In order to apply the openSUSE defaults, make sure /etc/polkit-default-privs.local does not contain any overrides, otherwise these will be applied on top of the defaults when running set_polkit_default_privs.

9.4. For more information

PolicyKit: http://hal.freedesktop.org/docs/PolicyKit/
polkit: http://hal.freedesktop.org/docs/polkit/