packagekit/docs/security.txt
2009-07-13 10:45:24 +01:00

79 lines
3.8 KiB
Plaintext

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.