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
|
tags
|
||||||
*.patch
|
*.patch
|
||||||
NEWS.new
|
NEWS.new
|
||||||
*.txt
|
|
||||||
.lock-wscript
|
.lock-wscript
|
||||||
.waf-*
|
.waf-*
|
||||||
_build_
|
_build_
|
||||||
|
1
docs/api/.gitignore
vendored
1
docs/api/.gitignore
vendored
@ -4,6 +4,7 @@ Makefile.libs
|
|||||||
*.bak
|
*.bak
|
||||||
*.gcno
|
*.gcno
|
||||||
*.out
|
*.out
|
||||||
|
*.txt
|
||||||
tmpl
|
tmpl
|
||||||
xml
|
xml
|
||||||
html
|
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