On 32 bit systems long will overflow in 2038, causing complete breakage.
This is confirmed by running dbus's test suite on a 32 bit system
with system time set to 2040 (and configured to use 64 bit time_t of course).
Note that both timespec and timeval are specified with time_t for the
seconds component. This should propagate everywhere where that data is
passed and stored, but previously _dbus_get_monotonic_time() and
_dbus_get_monotonic_time() would truncate it to long.
Also add a function for parsing dbus_int64_t from
files, as existing functions can only handle long.
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
If we have a large number of connections to the bus, and we fail to
reload the policy for one of them (perhaps because its uid no longer
exists in the system user database), previously we would crash, which
is obviously unintended. After the previous commit, we would stop
iteration through the list of client connections, which doesn't seem
great either: one bad connection shouldn't prevent us from reloading
the rest of our state.
Instead, let's distinguish between new connections (where we want
failure to establish a security policy to be fatal), and pre-existing
connections (where the current security policy is presumably good
enough to keep using if we have nothing better). If we're unable to
reload the policy for a pre-existing connection, log a warning and
carry on iterating.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/343
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, if dbus_connection_get_unix_user() succeeded but
_dbus_unix_groups_from_uid() failed, then bus_connection_get_unix_groups()
would incorrectly fail without setting the error indicator, resulting
in "(null)" being logged, which is rather unhelpful.
This also lets us distinguish between ENOMEM and other errors, such as
the uid not existing in the system's user database.
Fixes: 145fb99b (untitled refactoring commit, 2006-12-12)
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/343
Signed-off-by: Simon McVittie <smcv@collabora.com>
If policy creation fails, we can't usefully leave a NULL policy in the
BusConnectionData. If we did, the next attempt to reload policy would
crash with a NULL dereference when we tried to unref it, or with
an assertion failure.
One situation in which we can legitimately fail to create a client policy
is an out-of-memory condition. Another is if we are unable to look up a
connection's supplementary groups with SO_PEERGROUPS, and also unable to
look up the connection's uid's groups in the system user database, for
example because it belongs to a user account that has been deleted (which
is sysadmin error, but can happen, particularly in automated test systems)
or because a service required by a Name Service Switch plugin has failed.
Keeping the last known policy is consistent with what happens to all
the connections that are after this one in iteration order: after we
early-return, all of those connections retain their previous policies
(which doesn't seem ideal either, but that's how this has always worked).
[smcv: Add commit message]
Co-authored-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/343
Normally, it's enough to rely on a message being given a serial number
by the DBusConnection just before it is actually sent. However, in the
rare case where the policy blocks the driver from sending a message
(due to a deny rule or the outgoing message quota being full), we need
to get a valid serial number sooner, so that we can copy it into the
DBUS_HEADER_FIELD_REPLY_SERIAL field (which is mandatory) in the error
message sent to monitors. Otherwise, the dbus-daemon will crash with
an assertion failure if at least one Monitoring client is attached,
because zero is not a valid serial number to copy.
This fixes a denial-of-service vulnerability: if a privileged user is
monitoring the well-known system bus using a Monitoring client like
dbus-monitor or `busctl monitor`, then an unprivileged user can cause
denial-of-service by triggering this crash. A mitigation for this
vulnerability is to avoid attaching Monitoring clients to the system
bus when they are not needed. If there are no Monitoring clients, then
the vulnerable code is not reached.
Co-authored-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus/dbus#457
The full license texts are not added because they were already
added in a previous commit.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
see #394
Each connection that is an active monitor holds a pointer to its own
link in this list, via BusConnectionData.link_in_monitors. We can't
validly free the list while these pointers exist: that would be a
use-after-free, when each connection gets disconnected and tries to
remove itself from the list.
Instead, let each connection remove itself from the list, then assert
that the list has become empty.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/issues/291
It wasn't immediately clear from the names of these method whether they
should return TRUE or FALSE for queued owners other than the primary
owner. Renaming them makes it obvious that the answer should be TRUE.
While I'm there, make the corresponding _dbus_verbose() messages more
precise.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/issues/270
This extends dbus-daemon with support for send_destination_prefix
attribute in XML policies.
It allows having policy rules for sending to bus names generated
within namespaces defined by a prefix. The similar behaviour can be
emulated by owning an additional name, not used for addressing messages,
as described in
https://lists.freedesktop.org/archives/dbus/2017-May/017188.html
However, introducing send_destination_prefix creates possibility
of communicating intentions in a more direct way, which is easier
to understand.
Signed-off-by: Adrian Szyndela <adrian.s@samsung.com>
Change-Id: I0016ad93f1c16b7742fef5f45ebaf01b55694d3c
We don't usually mass-remove trailing whitespace from the actual source
code because it would complicate cherry-picking bug fixes to older
branches, but that reasoning doesn't really apply to the comments
containing copyright and licensing notices.
Removing trailing whitespace makes it much easier to move code around:
we have a commit hook that rejects commits containing trailing
whitespace, but that commit hook counts moving a file as a delete + add
pair, so it objects to moving code that contains trailing whitespace.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These do not appear in code coverage statistics, and `git grep`
reveals that they are unused.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107739
groups is never NULL here, but *groups can be NULL on OOM, and that's the
check that was intended.
Coverity ID 265358.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103737
Reviewed-by: Simon McVittie <smcv@collabora.com>
This saves a couple of _dbus_strdup/dbus_free pairs.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103737
If we avoid consulting the userdb, then it's one less chance to
deadlock.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103737
Reviewed-by: Philip Withnall <withnall@endlessm.com>
We'll need this if we want to stamp optional header fields on the
message according to the preferences of the recipient(s).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101899
We will eventually want to have other ways to signal that a
container server should stop listening, so that the container manager
doesn't have to stay on D-Bus (fd-passing the read end of a pipe
whose write end will be closed by the container manager has been
suggested as easier to deal with for Flatpak/Bubblewrap), but for
now we're doing the simplest possible thing.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
While reviewing fd.o#101354, Philip Withnall pointed out that if we
rejected a connection in the new code there, we didn't log why. It
turns out we didn't log that in the more normal code path either.
Redo the error handling so that failure to set up a connection
is logged.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103592
sidget and sidput functions are noop and deprecated since libselinux 2.0.86.
Also use pkg-config to detect libselinux and force version >= 2.0.86
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100912
Reviewed-by: Simon McVittie <smcv@collabora.com>
This is almost certainly not going to make a difference, as it’s on the
OOM handling path; but the fewer leaks the better.
Coverity ID: 141058
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99612
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The code counting pending fds relied on restart of timeouts when they are
enabled. This patch adds function that ensures that such enabled timeouts
have their timekeeping data reset (and not only when timeout is
registered into event loop processing).
When timeouts weren't reset, they'd fire at rather random and mainly
incorrect moments leading to interruption of connections of dbus-daemon.
Every time we reset the interval, we also need to re-enable the timeout
and mark its end time to be recalculated by the event loop, so combine
the old set_enabled(TRUE) with set_interval() as a new restart() method.
This leaves all the set_enabled() calls having a FALSE parameter, so
remove the parameter and rename the method to disable().
[smcv: fix minor coding style issues]
[smcv: replace set_reenabled()/set_interval() pair with restart()]
[smcv: replace set_enabled(FALSE) with disable()]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95619
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We specifically do not check recipient policies, because
the recipient policy is based on properties of the
recipient process (in particular, its uid), which we do
not necessarily know until we have already started it.
In this initial implementation we do not check LSMs either,
because we cannot know what LSM context the recipient process
is going to have. However, LSM support will need to be added
to make this feature useful, because StartServiceByName is
normally allowed in non-LSM environments, and is more
powerful than auto-activation anyway.
The StartServiceByName method does not go through this check,
because if access to that method has been granted, then
it's somewhat obvious that you can start arbitrary services.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
This is a workaround for
<https://bugs.freedesktop.org/show_bug.cgi?id=95263>. If a service
sends a file descriptor sufficiently frequently that its queue of
messages never goes down to 0 fds pending, then it will eventually be
disconnected. logind is one such service.
We do not currently have a good solution for this: the proposed
patches either don't work, or reintroduce a denial of service
security vulnerability (CVE-2014-3637). Neither seems desirable.
However, we can avoid the worst symptoms by trusting uid 0 not to be
malicious.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95263
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1591411
Reviewed-by: Łukasz Zemczak
Tested-by: Ivan Kozik
Tested-by: Finn Herpich
Tested-by: autostatic
Tested-by: Ben Parafina
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If it is set (i.e. if an LSM is in use) this will make it appear in
various places in log output.
With SELinux, for example, this appends something like:
label="system_u:object_r:unlabeled_t:s0"
This commit partially rearranges the code which sets the loginfo string,
so that it consistently puts a space between fields, and not one at the
end.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68212
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is either a denial-of-service attempt, a pathological performance
problem or a dbus-daemon bug. Sysadmins should be told about any of
these.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86442
[smcv: add units to timeout: it is in milliseconds]
Signed-off-by: Simon McVittie <smcv@debian.org>
This means we respect the destination keyword in arguments to
BecomeMonitor.
In bus_dispatch(), this means that we need to defer capturing until
we have decided whether there is an addressed recipient; so instead
of capturing once, we capture at each leaf of the decision tree.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92074
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Reviewed-by: Lars Uebernickel <lars@uebernic.de>
Every DBusConnection in the dbus-daemon should have been through
bus_connections_setup_connection(), so we can assert that the
BusConnectionData has been attached to it. Having this assertion
is enough to hint to Coverity that it does not need to worry about
whether this pointer might be NULL.
In regression tests, we do work with a few fake client-side
DBusConnection instances in the same process; but it would be a
serious bug if we mixed those up with the ones processed by
dbus-daemon's real code, so the assertion is still valid.
This patch has been inspired by (and fixes) the following coverity scan issues:
CID 54846: Dereference null return value (NULL_RETURNS).
CID 54854: Dereference null return value (NULL_RETURNS).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[smcv: fixed -Wdeclaration-after-statement; more informative commit message]
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
When an AppArmor confined process wants to acquire a well-known name, a
check is performed to see if the action should be allowed.
The check is based on the connection's label, the bus type, and the name
being requested.
An example AppArmor rule that would allow the name
"com.example.ExampleName" to be acquired on the system bus would be:
dbus bind bus=system name=com.example.ExampleName,
To let a process acquire any name on any bus, the rule would be:
dbus bind,
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Signed-off-by: John Johansen <john.johansen@canonical.com>
[tyhicks: Use BusAppArmorConfinement, bug fixes, cleanup, commit msg]
[tyhicks: initialize reserved area at the start of the query string]
[tyhicks: Use empty string for NULL bustypes when building queries]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When processes connect the bus, the AppArmor confinement context should
be stored for later use when checks are to be done during message
sending/receiving, acquire a name, and eavesdropping.
Code outside of apparmor.c will need to initialize and unreference the
confinement context, so bus_apparmor_confinement_unref() can no longer
be a static function.
[Move bus_apparmor_confinement_unref back to its old location for
a more reasonable diff -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75113
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Unlike eavesdropping, the point of capture is when the message is
received, except for messages originating inside the dbus-daemon.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This is a special connection that is not allowed to send anything,
and loses all its well-known names.
In future commits, it will get a new set of match rules and the
ability to eavesdrop on messages before the rest of the bus daemon
has had a chance to process them.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46787
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.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>
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>
The message bus which can monitor its conf dirs for changes and reload
confs immediately if dir monitor enabled, for example, inotify in Linux,
kqueue in *BSD.
However, it doesn't apply policy rules change for completed connections,
so to apply policy rules change, the client connection has to disconnect
first and then re-connect to message bus.
For imcomplete connections, it always has the latest review of policy
rules.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39463
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.
The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.
First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
