Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


The Gnome world starts to heavily use PolicyKit in their latest versions, and we get more and more requests to support it.

For Hardy we want to gently introduce it and discuss the security, usability, and maintenance ramifications of it. We ship PK by default and use it instead of our home-grown libpam-foreground, as well as for gnome-mount and hal.

Release Note

The user-visible behaviour does not change drastically, thus this is not really worth mentioning in the release notes.


Applications which use gksu today (such as gnome-system-tools or mounting an internal hard disk) currently run with root privileges. PolicyKit allows these to run as normal user with just getting a particular bit of extra privileges, so they can be controlled better, and in a more flexible way.

PolicyKit also provides the possibility of only allowing a particular privilege to an active (foreground) session, which provides a more robust and upstream supported variant of libpam-foreground, which we can then stop maintaining.

Use Cases



Replacing libpam-foreground

The only users of libpam-foreground at the moment are gnome-power-manager and gnome-volume-manager. Before doing any action they query /bin/check-foreground-console and inhibit the action if it returns false. However, this does not really enforce this policy (since any other application can invoke the dbus calls even in an inactive session), and requires us to maintain libpam-foreground which never got any upstream adoption, and the respective patches in g-p-m and g-v-m. We would even need to patch nm-applet to do the same, since network-manager has the same problem. Thus:


In Gutsy, gnome-mount carried a large patch to check if the mount operation failed due to insufficient privileges (which happened when attempting to mount an internal fixed disk as normal user), and call itself through gksu with appropriate arguments in that case. Since upstream supports PK integration, we use that in Hardy instead:

Security considerations

Once you compromise the user account of an administrator with a Trojan horse, then there are many ways to extend that to other users and root. The easiest way is to just produce a dialog with a reasonable (bogus) reason and ask for the password. This will probably work with the vast majority of users, and it is principally hard to avoid, thus we do not cover this interactive case here.

The more interesting side of this is avoiding ways to steal the password or privileges in a way that does not leave any traces, which is why this deserves some deeper analysis:

Weaknesses when using gksu:

To mitigate these, gksu would need a major design and implementation overhaul. In the past we made an explicit design decision to keep TTY tickets for usability reasons, so this is not going to change.

Weaknesses when using PolicyKit:

Contrary to gksu, there are no TTY tickets. The PolicyKit daemon assigns privileges based on the PID and executable name (to defend against PID reuse/wrapping). Also, the application only gets one particular privilege instead of full root powers.

To mitigate above two weaknesses, polkit-gnome-manager and applications which use PK should defend themselves against ptrace().

Thus using PK generally provides slightly better proactive security than gksudo (notwithstanding the fact that Trojans can do whatever they want with just a tad of social engineering anyway, see above).



ptrace() protection

The easiest way to achieve this at runtime is to do prctl(SET_DUMPABLE, 0). After that, other processes like strace or gdb cannot attach to this process any more and grab the password from memory.

This is by far not reliable: You can attach gdb to the process before it reaches the prctl(), and either just stay connected or patch it out. More robust methods would be:

A local trojan can always spoof credible gksu/PK dialogs itself, so this is only a mild stop-gap measure anyway and thus does not warrant intrusive hacks. Solving this problem properly would involve a complete MAC lockdown of desktops, which we do not want to do at least right now for usability reasons.

Thus we go with the prctl() approach.

For Hardy, this affects many more application than just the ones using PolicyKit: gksu, ssh, gnupg, gnome-screensaver, and others which store passwords into their memory.


A somewhat delicate point is the definition of an 'administrator'. So far the definitive place in Ubuntu was /etc/sudoers, but PolicyKit is not able to parse this and decide about who is an administrator. Also, sudoers can be much more fine-grained than just assigning the ALL privilege to an user, but this configuration does not map at all to PK privileges (which are abstract and arbitrary concepts like "mount a fixed internal disk" or "suspend the machine" and not tied to executables).

The default Ubuntu setup is to grant full sudo privileges to members in admin, which maps well to the change outlined above.

Test/Demo Plan

  1. Call System → Administration → Users and Groups. You immediately get a read-only view of the current users and groups without being asked for your password immediately. Press "Unlock", you'll get a dialog for entering your password for authentication. After that you can change settings.
  2. The same authentication dialog should also appear if you try to mount an internal fixed hard disk partition in the computer place or the drivemount applet.


DesktopTeam/Specs/PolicyKitIntegration (last edited 2008-08-06 16:34:36 by localhost)