Status of Policy Kit

[David Zeuthen]

On Wed, 2007-04-25 at 19:32 +0530, Sayamindu Dasgupta wrote:
> Hello everyone,
> I am working on extending the GNOME lockdown framework as a part of my
> Google SoC project[1], and I was wondering if someone could tell me
> what the status of PolicyKit and the associated GUI as outlined in
> http://lists.freedesktop.org/archives/hal/2006-January/004377.html is.

So, what happened was that, about four weeks ago, I started rewriting
all the PolicyKit stuff from scratch. Most of the core stuff is already
there and working. I haven't, yet, gotten down to writing a big document
explaining how it works, what it does, why it's needed etc. etc. But am
planning to start on that aspect this week; will reply to this thread
once I have something. Sounds OK?

Regarding the GUI work right now I have working dialogs like these

 http://people.freedesktop.org/~david/polkit-shutdown-multiple.png
 http://people.freedesktop.org/~david/polkit-mount-fixed.png

that are triggered by a session-wide D-Bus service; e.g. applications
(like gnome-mount) who are told by e.g. HAL that a certain method cannot
be invoked (because HAL says libpolkit doesn't say 'yes') just calls
into org.gnome.PolicyKit and the session daemon (possibly activated)
handling that service prompt the user for authentication. This is in the
PolicyKit-gnome project; it's not yet in GNOME SVN but will be shortly
as gnome-mount and other stuff is going to depend on it.

Also, I'm going to write another piece of UI for configuring actions/
policy akin to e.g. this mockup

> +------------------------------------------------+
> | The following users and groups are allowed to  |
> | mount the volume 'Dave's USB key':             |
> |      +-------------------------------+         |
> |      | U dave                       ^|         |
> |      | U dogbert                    ||         |
> |      | G coolkids                   V|         |
> |      +-------------------------------+         |
> |       [Delete] [Add Group] [Add User]          |
> |                                                |
> | The following users and groups are not allowed |
> | to mount the volume 'Dave's USB key':          |
> |      +-------------------------------+         |
> |      | U bert                       ^|         |
> |      | U osama                      ||         |
> |      | G lamers                     V|         |
> |      +-------------------------------+         |
> |       [Delete] [Add Group] [Add User]          |
> |                                                |
> |                                        [Close] |
> +------------------------------------------------+

and others from the 2006 "ramblings about privileges" mail. It's not
going to look exactly like this but will provide the same functionality.

I think it might be worth mentioning where I draw the line between what
need to be handled through PolicyKit and what should be handled by the
GNOME lockdown framework.

Basically, my view is that every privileged operation [1] that is
offered through the desktop, needs to be able to be locked down. This
ideally needs to happen through a secure centralized framework and
PolicyKit is my answer to that.

I note that you are using the term "GNOME lockdown". This is a very
broad and slightly confusing term. I presume that you're mostly
referring to the gconf feature called "mandatory settings", e.g. the act
of tagging a preference item in the gconf database such that the user
cannot override the value. Did you have anything else than gconf
mandatory settings in mind?

Basically I think that "gconf mandatory settings" is a very useful
feature that we're definitely not using enough in GNOME. However, this
feature _cannot_ be used to control access to privileged operations
since privileged system-level mechanisms (such as HAL) can't nor
shouldn't depend on gconf. 

Anyway, the mechanism (such as HAL), in order to be secure, needs to
verify whether a user actually should be allowed to carry out a
privileged action (such as connecting to a random wireless network),
e.g. it's not at all enough that we, by using gconf mandatory settings,
tell NM's gnome applet to avoid doing that; we need the system-wide NM
daemon to actually check this since it, by design, cannot and should not
trust the UI applet. Hence PolicyKit.

Btw, there's a bunch of other useful and cool things we should be doing
with gconf mandatory settings. But access to privileged operations just
cannot be one of them cf. my explanation below. E.g. we cannot use gconf
when there's a privilege boundary in the equation.

Lock-down-ish things that I think should be done using gconf mandatory
settings includes (some of these may be done already)

 - Don't allow file browser to show files outside $HOME
 - Disable run-as dialog
 - Have black/white-list of apps to show in the menus (and other places)
   - perhaps even enforce these lists in key GTK+/GNOME API's
 - Lockdown of g-p-m (e.g. cannot change the policy)
 - Screensaver (e.g. cannot change/disable the screensaver)
 - Background picture
 - IRC/IM clients (white/black-list of networks to connect to)
 - ...

but now I'm wildly off-topic.

So I guess I'm saying there's room for two [2] mechanisms. It's not
ideal, however, there will be two ways of configuring the system, for
example

 - What desktop background we force the users to use
   (configured via a gconf mandatory setting)

vs.

 - Whether we forbid users to mount USB drives
   (configured via PolicyKit)

However, in a very real sense these are two very different classes of
policy. The former represents administrative policy while the latter
represents _security_ policy. So perhaps, especially with the advent of
things like XCCDF [3], it's not a bad idea that security sensitive
policy is configured in a separate place. Something to think about.

Anyway, that was a long response. Did it make any sense? Otherwise just
ask and I'll try to explain a bit more.

     David

[1] : with "privileged operation" I mean anything the user does that
requires privileges:

 - mounting removable/fixed media
 - managing network connections
 - formatting/managing disks
 - burning cd's
 - managing audio devices
 - installing/removing/upgrading software
 - setting the date/timezone
 - managing bluetooth devices
 - and so on...

[2] : and if you support KDE too you'll have to lock down the desktop
background, you'll have a third place as well!

[3] : http://nvd.nist.gov/scap/xccdf/xccdf.cfm