GNOME privilege library

[Sean Middleditch <elanthis awesomeplay com>]

The debate on libgnomesu has pretty much made the main objections clear.
The library is designed for a single, specific use-case tied to a
specific implementation that is not ideal.

GNOME needs a way to handle a general problem (that has many use cases)
and can handle it using different implementations for different base
operating systems.

The general problem is that certain applications need escalated
privileges in order to perform certain tasks.  These tasks can be
something the whole application is centered around (such as a system log
viewer) or only several features of the application (renice support in
procman).

The specifics of the user interaction for performing these tasks aren't
really specified, and I'm not sure they *can* be specified fully, since
in many cases the UI is based on the authentication mechanism.  I will
assume that all authentication is based on challenge-response
interactions, where the system asks the user to perform an action (such
as type in a password) and then verifies the action.  (Are there any
authentication systems around that this model does not work for?)

What I'd like to do is lay down some ideas on how the eventual GNOME
framework for handling privileges should work, not in concrete
implementation details but in the general design and requirements.
Forming an API and an implementation of that API can happen after we
have a good idea of what exactly we want and what it needs to do.

First is the issue of running an application as root vs running an
application as a user with a privileged backend.  Running the
application itself as root should be avoided whenever possible.  Running
the application as root has several serious disadvantages:

 - general lack of trust in the security of xlib or GTK (the developers
of each have stated as much)
 - apps running as root don't look or act like the rest of the apps on
the user's desktop in many cases; an easy to see example is when the
user has a custom theme installed in ~/.themes
 - apps running as root must either start as root or not run as root at
all, they have no way to raise or lower privileges once started

The case against using a backend process with a non-privileges front-end
has mostly to do with complexity.  There is a need to be able to
arbitrarily start and stop a backend with or without privileges and to
communicate with that backend safely.  Writing the code to manage this
is very low-level and error-prone.  I believe that the GNOME framework
should provide simple API to manage this scenario so that more apps can
quickly, easily, and securely build an application that uses a
privileged backend.

This gets to the main point.  The GNOME privilege API should not be
built around invoking an application, but instead should be built
entirely around starting and communicating with a backend process.

The trickiest part of this is, of course, the authentication itself.
The problem with libgnomesu is that it's built around the idea of
starting an application as a specific user.  That is an implementation
detail.  On an SELinux using system, there may be no need to run as root
- simply switch to using a more privileged role.  On a sudo-using system
the sudo rules should be used.  On a system that already provides a rich
authentication-management solution such as consolehelper, that system
should be utilized.

Additionally, random applications should not be able to just start any
process with privileges.  Imagine a trojan application a user downloads
that informs the user it needs root privileges and pops up the
authentication dialog; this is an easy and common social-engineering
attack.  If, instead, the framework only allows certain apps to be
started with privileges, this attack cannot work.  While consolehelper
takes this approach, it cannot be relied on since many OSes do not
provide it, and others specifically do not want to use it.

Again, the GNOME privilege framework should not depend on implementation
details of the authentication system.  But it should take this security
situation into consideration.  A simple way to manage this is for the
API to not take a path to a binary, but instead to take the name/ID of a
registered privilege-requiring service.  For example, the procman
install notes that it uses /usr/libexec/gnome-procman-renice as a
backend.  A file (or system-only GConf key, perhaps?) notes this
relationship.  Procman can ask to run its renice backend and
authentication proceeds as normal.  If Procman asks to run /bin/rm, the
API would note that is not a registered backend and refuse.
Additionally, the registration can note with processes can use which
backend.  /usr/libexec/gnome-procman-renice is only registered
to /usr/bin/gnome-procman, for example.  If ~/Downloads/random-trojan
tries to use it the API would refuse, until the administrator granted
that binary access.  It's notable that SELinux already provides this
feature - but again, we cannot rely on it being available everywhere
GNOME is used.

Finally, the library API does *not* care about how a backend is started
or how the authentication happens.  The API allows an application to
invoke a backend and check its status (not running, running privileged,
running unprivileged, starting, authenticating).

All the application developers think of is "start backend, send backend
messages and read responses."  THe specifics of how and when the backend
is started is something I'll leave up to the usability folks - it could
be the OS X lock-icon method or whatever else is decided upon.  In the
short-term, apps that need privileges could start the backend on app
startup or whenever a specific feature is used that requires privileges.

Summary of API:
  - all privileges are in backend processes, not the GUI application
    itself
  - applications can start and stop the backend process at any time
  - API provides clean and safe abstraction over starting and
    communicating with the backend process
  - API does not make *any* assumptions about authentication system in
    use on the system
  - API is pro-active on security by only allowing certain applications
    to use certain backend

The final piece of the puzzle is in regards to the backend/application
registration.  This does get rather complicated, and I'd understand
punting/ignoring this issue, although I do believe the security benefit
is *definitely* worth it.

The idea here is pretty simple.  A CLI utility is provided that takes a
path to a backend binary and a frontend binary.  The utility just adds
them to the registration list (be this some file database somewhere or
system-write-only GConf keys).  The utility also has a remove option.
The utility only runs as root.  This mechanism provides security
features not found on most boxes (what app can invoke which other app,
at least in the case of privileged backends).

Now, the privilege library can be implemented using a number of
different methods.  Shipping something like the libgnomesu method makes
sense for systems that have no alternatives.  It's very worthwhile to
note that the privileges utility that launches the backends (gnome-su)
is responsible for checking the privileged backend control list -
otherwise, user apps could just directly ask the privilege tool to
launch any backend app.

Do the requirements and general design seem acceptable?  Are there any
use-cases that we want to support that this will not work for?  Are
there any additional features that we need?  Is there any authentication
system that this cannot handle?  Any general objections?

If the requirements/design look right then we can have a good start at
getting a solid, acceptable-to-all privilege library in GNOME for
2.10/2.12 that procman, logview, gst, and so on could use.  We could
even hope that utilities like red-carpet or system-install-packages or
synaptic or whatever could use the library, providing a consistent,
powerful, usable interface for apps that require privilege.