82 lines
4.1 KiB
Plaintext
82 lines
4.1 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
|
|
| ___/
|
|
[D-Bus] __[D-Bus]__/
|
|
| /
|
|
packagekitd -- [D-Bus] -- polkitd-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 D-Bus. 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 polkitd-1 service.
|
|
|
|
When a privileged method is executed, the daemon checks with polkitd-1 daemon
|
|
for whether the client is authorized for the action it wants to perform.
|
|
This may involve the user authenticating that they are either the user (by
|
|
typing their password) or that they are an administrative user (by typing the
|
|
root password or the password of a user designated as an administrative user).
|
|
The authorization check can take some time, but the daemon can process other
|
|
requests whilst waiting for user input.
|
|
|
|
The packagekitd daemon is started using D-Bus 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.
|
|
|