Security and PackageKit

This document is a brief overview of security policies and notes about security
in the PackageKit project. It has been written by the PackageKit authors, and
should not be treated as independent analysis. This document has been written as
packagekitd is a system activated daemon running as the root user (uid 0), which
means the package management system is run as root also. The daemon receives
untrusted input from the client, which means the daemon is security sensitive.

First, a high level overview, in this case using the yum backend as an example:

  gpk-update-icon      gpk-application
        |              _______/
     [DBUS] __[DBUS]__/
        |  /
   packagekitd -- [DBUS] -- polkit-daemon-1
        |
      [pipe]
        |
   yumBackend.py (using yum)

packagekitd does not expose itself remotely over XMLRPC or other remote
interface, and so a remote denial of service or exploit is impossible without a
serious exploit of other services such as DBus. It advertises a simple interface
that can be queried by clients in unprivileged and privileged modes.
The privileged modes are controlled using PolicyKit, and policy and the
authentication mechanism is deferred to the polkit-daemon-1 service.

When a privileged method is executed, the daemon asks polkit-daemon-1 for
authentication, which then blocks until the authentication is completed. This
is handled asynchronously, and the daemon can process other requests whilst
waiting for user input.

The packagekitd daemon is started using DBus system activation, which means it
is started without any environment (no PATH, etc) and therefore is impossible to
exploit by preloading other libraries. It is also running as uid 0, and so
requires root privileges to inject code into it.

A typical transaction would be for the client to request a TID (transaction ID)
to which the server responds by creating a transaction instance and exposing
this on the system bus. The client then connects to this interface, and executes
the chosen method. This method will emit signals such as ::Package(), then
::Finished() and then after a number of seconds ::Destroy() which will remove
the interface from the bus.

Attack vectors:

 * A client could cause a local DoS (denial of service) by repeatedly calling
 GetTid without then calling a method to use this TID. This is mitigated by
 timing out Tid request after a present number of seconds, and the effect can be
 limited with a config variable (SimultaneousTransactionsForUid).

 * Local DoS by repeatedly calling non-privileged methods such as Resolve and
 SearchName. This could be mitigated by limiting the number of requests per
 second for a certain seat, although no code has been written to do this at
 present.

 * A privileged method could be requested and then ignored or hidden by the
 window manager. This is mitigated by not blocking the daemon when processing
 authentication, and timing-out the authentication after a number of seconds if
 authentication credentials are not supplied.

 * Passing untrusted input to the backend which could be used to crash and
 exploit the underlying package system. This is mitigated by rejecting invalid
 input to methods, and testing filenames for existence before they are passed
 to the backend.

 * A session service can be written to automatically authenticate methods, and
 replace the native client. This is hard to mitigate, as as soon as you have
 untrusted code running in the session, it's very easy to load exploit code
 using GTK_MODULES into previously trusted applications, such as gpk-application.

 * Issuing a large amount of data to a method to cause a local denial of
 service, for instance calling Resolve with millions of parameters. This is
 mitigated in the daemon by checking for a sane number of requests
 (MaximumPackagesToProcess) for each method, and also limiting the total length
 of the data.