These function calls are not a privilege escalation risk like
UpdateActivationEnvironment, but they might provide sensitive
information or be enhanced to provide sensitive information
in future, so the default system.conf locks them down to root-only.
Apply the same canonical-object-path hardening as for
UpdateActivationEnvironment.
We do not apply the uid check here because they are less dangerous
than UpdateActivationEnvironment, and because the ability to unlock
these function calls for specific uids is a documented configuration
for developers.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[added missing #include; extended commit message -smcv]
As with the previous commit, this is probably not actually privilege
escalation due to the use of an activation helper that cleans up its
environment, but let's be extra-careful here.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[adjusted commit message -smcv]
UpdateActivationEnvironment is the one dbus-daemon API call that is
obviously dangerous (it is intended for the session bus),
so the default system.conf does not allow anyone to call it.
It has recently come to the D-Bus maintainers' attention that some
system services incorrectly install D-Bus policy rules that allow
arbitrary method calls to any destination as long as they have a
"safe" object path. This is not actually safe: some system services
that use low-level D-Bus bindings like libdbus, including dbus-daemon
itself, provide the same API on all object paths.
Unauthorized calls to UpdateActivationEnvironment are probably just
resource consumption rather than privilege escalation, because on
the system bus, the modified environment is only used to execute
a setuid wrapper that avoids LD_PRELOAD etc. via normal setuid
handling, and sanitizes its own environment before executing
the real service. However, it's safest to assume the worst and
treat it as a potential privilege escalation.
Accordingly, as a hardening measure to avoid privilege escalation on
systems with these faulty services, stop allowing calls to
("/com/example/Whatever",
"org.freedesktop.DBus.UpdateActivationEnvironment")
and only allow ("/org/freedesktop/DBus",
"org.freedesktop.DBus.UpdateActivationEnvironment").
We deliberately continue to provide read-only APIs like
GetConnectionUnixUser at all object paths, for backwards compatibility.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[adjusted commit message to note that this is probably only DoS -smcv]
This reverts commit 54d26df52b.
It appears this change may cause intermittent slow or failed boot,
more commonly on slower/older machines, in at least Mageia and
possibly also Debian. This would indicate that while the system
is under load, system services are not completing authentication
within 5 seconds.
This change was not the main part of fixing CVE-2014-3639, but does
help to mitigate that attack. As such, increasing this timeout makes
the denial of service attack described by CVE-2014-3639 somewhat
more effective: a local user connecting to the system bus repeatedly
from many parallel processes can cause other users' attempts to
connect to take longer.
If your machine boots reliably with the shorter timeout, and
resilience against local denial of service attacks is important
to you, putting this in /etc/dbus-1/system-local.conf
or a file matching /etc/dbus-1/system.d/*.conf can restore
the lower limit:
<busconfig>
<limit name="auth_timeout">5000</limit>
</busconfig>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86431
This makes bus_context_check_security_policy follow convention of
setting errors if function indicates failure and has error parameter.
Notable implication is that AccessDenied error will be sent if sending message
to addressed recipient is denied due to receive rule. Previously, message
was silently dropped.
This also fixes assertion failure when message is denied at addressed recipient
while sending pending auto activation messages.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86194
This ensures that our rlimit is actually high enough to avoid the
denial of service described in CVE-2014-3636 part A.
CVE-2014-7824 has been allocated for this incomplete fix.
Restore the original rlimit for activated services, to avoid
them getting undesired higher limits.
(Thanks to Alban Crequy for various adjustments which have been
included in this commit.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=85105
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69702
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Tested-by: Patrick Welche <prlw1@cam.ac.uk>
As an implementation detail, dbus-daemon handles this situation by
artificially triggering a timeout (even if its configured timeout for
method calls is in fact infinite). However, using the same debug message
for both is misleading, and can lead people who are debugging a service
crash to blame dbus-daemon instead, wasting their time.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=76112
This is one of four commits needed to address CVE-2014-3637.
The bus uses _dbus_connection_set_pending_fds_function and
_dbus_connection_get_pending_fds_count to be notified when there are pending
file descriptors. A timeout per connection is armed and disarmed when the file
descriptor list is used and emptied.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is one of four commits needed to address CVE-2014-3637.
When a file descriptor is passed to dbus-daemon, the associated D-Bus message
might not be fully sent to dbus-daemon yet. Dbus-daemon keeps the file
descriptor in the DBusMessageLoader of the connection, waiting for the rest of
the message. If the client stops sending the remaining bytes, dbus-daemon will
wait forever and keep that file descriptor.
This patch adds pending_fd_timeout (milliseconds) in the configuration to
disconnect a connection after a timeout when a file descriptor was sent but not
the remaining message.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This partially addresses CVE-2014-3639.
This will change the default on the system bus where the limit
<limit name="auth_timeout">...</limit>
is not specified.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919
Reviewed-by: Thiago Macieira <thiago@kde.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This addresses CVE-2014-3636.
Based on a patch by Alban Crequy. Now that it's the same on all
platforms, there's little point in it being set by configure/cmake.
This change fixes two distinct denials of service:
fd.o#82820, part A
------------------
Before this patch, the system bus had the following default configuration:
- max_connections_per_user: 256
- DBUS_DEFAULT_MESSAGE_UNIX_FDS: usually 1024 (or 256 on QNX, see fd.o#61176)
as defined by configure.ac
- max_incoming_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
- max_outgoing_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
- max_message_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS = usually 1024
This means that a single user could create 256 connections and transmit
256*4096 = 1048576 file descriptors.
The file descriptors stay attached to the dbus-daemon process while they are
in the message loader, in the outgoing queue or waiting to be dispatched before
D-Bus activation.
dbus-daemon is usually limited to 65536 file descriptors (ulimit -n). If the
limit is reached and dbus-daemon needs to receive a message with a file
descriptor attached, this is signalled by recvfrom with the flag MSG_CTRUNC.
Dbus-daemon cannot recover from that error because the kernel does not have any
API to retrieve a file descriptor which has been discarded with MSG_CTRUNC.
Therefore, it closes the connection of the sender. This is not necessarily the
connection which generated the most file descriptors so it can lead to
denial-of-service attacks.
In order to prevent DoS issues, this patch reduces DEFAULT_MESSAGE_UNIX_FDS to
16:
max_connections_per_user * max_incoming_unix_fds = 256 * 64 = 16384
This is less than the usual "ulimit -n" (65536) with a good margin to
accomodate the other sources of file descriptors (stdin/stdout/stderr,
listening sockets, message loader, etc.).
Distributors on non-Linux may need to configure a smaller limit in
system.conf, if their limit on the number of fds is smaller than
Linux's.
fd.o#82820, part B
------------------
On Linux, it's not possible to send more than 253 fds in a single sendmsg()
call: sendmsg() would return -EINVAL.
#define SCM_MAX_FD 253
SCM_MAX_FD changed value during Linux history:
- it used to be (OPEN_MAX-1)
- commit c09edd6eb (Jul 2007) changed it to 255
- commit bba14de98 (Nov 2010) changed it to 253
Libdbus always sends all of a message's fds, and the beginning
of the message itself, in a single sendmsg() call. Combining these
two, a malicious sender could split a message across two or more
sendmsg() calls to construct a composite message with 254 or more
fds. When dbus-daemon attempted to relay that message to its
recipient in a single sendmsg() call, it would receive EINVAL,
interpret that as a fatal socket error and disconnect the recipient,
resulting in denial of service.
This is fixed by keeping max_message_unix_fds <= SCM_MAX_FD.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
This patch doesn't do any function change, but only the function name,
to align its name with the struct RestorePendingData.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=72254
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
How it should work:
When a D-Bus message activates a service, LSMs (SELinux or AppArmor) check
whether the message can be delivered after the service has been activated. The
service is considered activated when its well-known name is requested with
org.freedesktop.DBus.RequestName. When the message delivery is denied, the
service stays activated but should not receive the activating message (the
message which triggered the activation). dbus-daemon is supposed to drop the
activating message and reply to the sender with a D-Bus error message.
However, it does not work as expected:
1. The error message is delivered to the service instead of being delivered to
the sender. As an example, the error message could be something like:
An SELinux policy prevents this sender from sending this
message to this recipient, [...] member="MaliciousMethod"
If the sender and the service are malicious confederates and agree on a
protocol to insert information in the member name, the sender can leak
information to the service, even though the LSM attempted to block the
communication between the sender and the service.
2. The error message is delivered as a reply to the RequestName call from
service. It means the activated service will believe it cannot request the
name and might exit. The sender could activate the service frequently and
systemd will give up activating it. Thus the denial of service.
The following changes fix the bug:
- bus_activation_send_pending_auto_activation_messages() only returns an error
in case of OOM. The prototype is changed to return TRUE, or FALSE on OOM
(and its only caller sets the OOM error).
- When a client is not allowed to talk to the service, a D-Bus error message
is pre-allocated to be delivered to the client as part of the transaction.
The error is not propagated to the caller so RequestName will not fail
(except on OOM).
[fixed a misleading comment -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78979
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The algorithm to collapse a subsidiary config file's data into the
master data structure forgot to examine this flag.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73475
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[FreeBSD and OpenBSD contributors clarified that O_CLOEXEC has been
supported for ~ 2 years on both, so for the moment we're assuming
that every platform with kqueue also has working O_CLOEXEC. Please reopen
the bug, with a tested patch that uses _dbus_fd_set_close_on_exec() instead,
if this assumption turns out to be false. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=72213
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There is a DBusList* member of BusTransaction named "connections", while
its getter function bus_transaction_get_connections() returns
context->connections which in fact is a BusConnections pointer, this is
quite confusing. Because this is what bus_context_get_connections()
returns.
This patch call out to bus_context_get_connections() directly and remove
the then unused bus_transaction_get_connections().
https://bugs.freedesktop.org/show_bug.cgi?id=71597
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are memory blocks leak when doing bus-test, both dispatch-sha1 and
dispatch test cases complain memory blocks leak.
This patch also fix fd leaks.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69332
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
