[u-u] Privileged-access GUI

[Eric Siegerman]

At UU this past week, someone asked how system-configuration GUI
applets and the like get the privilege they need, given that they
start off unprivileged.

As was said at the meeting, PolicyKit is indeed the thing
involved, but it does *not* involve any new kernel mechanisms;
all it needs from the kernel is the familiar set[ug]id and an IPC
mechanism like D-Bus or pipes.  There are indeed fine-grained
privileges, but they're implemented wholly in user space.

The short version is that such an applet is split into two
processes -- an unprivileged client that handles the GUI, and a
set[ug]id server that does the work.

The trick is to arrange that the privileged server need not (and
indeed, must not) trust the GUI client, and that the client never
sees the typed-in password.  The way that works is:
  - Whenever the client makes a request to the server for a
    privileged operation, the server checks the PolicyKit
    database to see if the client is authenticated.  The first
    time, it isn't, so the server fails the request with a
    "you're not authenticated" error

  - The client calls a third process, the Authentication Agent,
    which is part of PolicyKit itself [a slight simplification]
    
  - It's the Authentication Agent that prompts for and verifies
    the password.  If the password matches, the Authentication
    Agent records the successful authentication in the database

  - The client retries the request; this time, since the
    database contains the necessary authentication entry, the
    server fulfills the request

There's more to it than that, the important bit being that
they're all passing around enough information, in the right
topology, to prevent various forms of spoofing.


The long version is here:
    http://hal.freedesktop.org/docs/PolicyKit/ref-design.html

The first two sections, "Introduction" and "PolicyKit Model",
describe the design on a conceptual level.

  - Eric