Add a security document after some initial review
This commit is contained in:
parent
d0e14db8cc
commit
9a276f6ec7
1
.gitignore
vendored
1
.gitignore
vendored
@ -51,7 +51,6 @@ py-compile
|
||||
tags
|
||||
*.patch
|
||||
NEWS.new
|
||||
*.txt
|
||||
.lock-wscript
|
||||
.waf-*
|
||||
_build_
|
||||
|
1
docs/api/.gitignore
vendored
1
docs/api/.gitignore
vendored
@ -4,6 +4,7 @@ Makefile.libs
|
||||
*.bak
|
||||
*.gcno
|
||||
*.out
|
||||
*.txt
|
||||
tmpl
|
||||
xml
|
||||
html
|
||||
|
78
docs/security.txt
Normal file
78
docs/security.txt
Normal file
@ -0,0 +1,78 @@
|
||||
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.
|
||||
|
Loading…
Reference in New Issue
Block a user