Age | Commit message (Collapse) | Author | Files | Lines |
|
MSG_CTRUNC indicates that we have received fewer fds that we should
have done because the buffer was too small, but we were treating it
as though it indicated that we received *no* fds. If we received any,
we still have to make sure we close them, otherwise they will be leaked.
On the system bus, if an attacker can induce us to leak fds in this
way, that's a local denial of service via resource exhaustion.
Reported-by: Kevin Backhouse, GitHub Security Lab
Fixes: dbus#294
Fixes: CVE-2020-12049
Fixes: GHSL-2020-057
|
|
Only for send/receive/own rules in default context.
Change-Id: Iabbbfa5d582f9993b832f49193da93225c645014
|
|
Change-Id: I2854f6cc51b26ff04a9984778f899ba9656ba290
|
|
Change-Id: I42926c107aae0be1a1247a61f3558122b07f9914
|
|
Change-Id: I573ddbc7e64bef38ed7517644bd842728e14679b
|
|
Change-Id: I6267b3c7cc6fead8c4dd37967c122e1597239ebf
|
|
No functional changes, just packed arguments to structs.
Change-Id: I0e5a22a208ba7085727e617c52cd061c39524967
|
|
No functional changes, just moving code around.
This extracts check_send_rule, check_receive_rule,
and check_own_rule from their own respective
bus_client_policy_can_check_* functions.
Change-Id: Ice4b2b96054b33a376bc3f48df29447747e7980e
|
|
This removes optimization, because in subsequent commits
we're going to apply:
* direct checking of policy
* hash tables instead of lists.
Change-Id: I6de32c4a29bac1d185f76eb88b22198c9ea22413
|
|
Change-Id: Ideba1fea470bc0d38c04f428b23270fe6176ac95
|
|
Pending replies will increasing
1) if client sending lots of messages to destination at once
2) if server eats incoming messages.(no reply)
In case of 2) dbus-daemon still has pending information.
With default bus context option (reply_timeout=-1) it never freed.
Assuming 2) happended repeatedly, then it is hard to detect until it
exceeds maximum pending replies limit, because of dbus-daemon print warning messages
only if pending replies over bus limit(default 1024 for system bus).
Change-Id: Iee0515fac68af7586547cc5ef5e6fa73d388a312
Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
|
|
Change-Id: I57c318bdf8a0e2d8d731c002185946930392718e
|
|
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
In an unprivileged container, uid 0 doesn't have CAP_SYS_RESOURCE, so
we can't expect the dbus-daemon to be able to escalate its fd limit.
This can be reproduced using bubblewrap:
sudo bwrap \
--cap-drop CAP_SYS_RESOURCE \
--ro-bind / / \
--dev /dev \
env \
DBUS_TEST_DAEMON=.../bus/dbus-daemon \
DBUS_TEST_DATA=.../test/data \
.../test/test-dbus-daemon \
-p /fd-limit \
--verbose
Bug-Debian: https://bugs.debian.org/908092
|
|
|
|
Commit 724adb2f6 mangled the dbus_message_append_args() code example.
This fixes it by breaking the lines and aligning at the right places.
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
|
|
|
|
Fixes compilation issues for case when X11 is not in a standard location
|
|
See merge request dbus/dbus!115
(cherry picked from commit fd41caa3664d480605628f08c217581bc42fa3e7)
|
|
|
|
The layout introduced with GVariant was kind of mimicking
the real structure, as opposed to the original layout, which
was taking into account only total sizes.
Dbus-1.10.8 introduced some static assertions for the properties of
DBusMessageIter. These are incompatible with the "GVariant" layout.
Moreover, they show that the "GVariant" layout could be prone to
the copying, that could omit some fields or parts of fields, due
to its not "packed" structure.
This commit brings back the original layout, with modifications
suited for GVariant-sized DBusMessageRealIter.
As an additional feature - this should fix compilation for 64-bit
architectures.
Change-Id: Ie1cac3748d408c22acf177ede5fb9e4e29818c9b
|
|
The two files: sysusers.d/dbus.conf and tmpfiles.d/dbus.conf
are always installed into {%_prefix}/lib, even if libdir is %{_prefix}/lib64
or %{_prefix}/lib/x86_86-linux-gnu or %{_prefix}/what/ever.
This commit fixes spec file to package the files from %{_prefix}/lib
instead of %{_libdir}.
Change-Id: I1f3a99f04c4bc880a9e38f77c112acdb61bbd4ad
|
|
Change-Id: Ie55319b9a3075a1f1f12afadecc6c06c39e3dd3b
|
|
|
|
|
|
- spec: drop deprecated option --with-init-scripts
- spec: package new, installed files
- spec: acknowledge removing of dbus.socket from dbus.target.wants
- spec: add autoconf-archive build dependency
- acknowledge renaming HACKING to CONTRIBUTING.md
- spec: bump version to 1.12.16
|
|
dbus 1.12.16
|
|
This reverts commit 8d7fa32af68f2ba1f5da3494ce6d50e8e7c2c034.
Change-Id: Iaf3890e804b87b7c6751237e0ef93b3ad5db9ceb
|
|
This reverts commit 873bad7e9515fbafb8682fa6cdadfee629762e0d.
Change-Id: I642e8ca08d551320b56d97e682c969689640700f
|
|
Debugging is difficult due to lack of error information:
When the broadcast signal is blocked by dbus policy,
unlike other types of dbus messages,
dbus-daemon does not print any error logs,
it just passes an error message to the bus monitor.
Change-Id: I9c6c55530d64451403664ea1eee4b703360691eb
|
|
[1.12] bus: Don't explicitly clear BusConnections.monitors
See merge request dbus/dbus!142
|
|
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
(cherry picked from commit b034b83b59efffd4cc819ad42d0cd078d91d53df)
|
|
doc: Fix environment variable name in dbus-daemon(1)
See merge request dbus/dbus!141
|
|
Spotted by Mubin. This documentation relates to the code in
add_bus_environment() in bus/activation.c.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #275
(cherry picked from commit bf71a58e4ab496c1726209aaad94a1abe670a01f)
|
|
The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership
of a shared home directory by having the server write a secret "cookie"
into a .dbus-keyrings subdirectory of the desired identity's home
directory with 0700 permissions, and having the client prove that it can
read the cookie. This never actually worked for non-malicious clients in
the case where server uid != client uid (unless the server and client
both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional
Unix uid 0) because an unprivileged server would fail to write out the
cookie, and an unprivileged client would be unable to read the resulting
file owned by the server.
Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings
is owned by the uid of the server (a side-effect of a check added to
harden our use of XDG_RUNTIME_DIR), further ruling out successful use
by a non-malicious client with a uid differing from the server's.
Joe Vennix of Apple Information Security discovered that the
implementation of DBUS_COOKIE_SHA1 was susceptible to a symbolic link
attack: a malicious client with write access to its own home directory
could manipulate a ~/.dbus-keyrings symlink to cause the DBusServer to
read and write in unintended locations. In the worst case this could
result in the DBusServer reusing a cookie that is known to the
malicious client, and treating that cookie as evidence that a subsequent
client connection came from an attacker-chosen uid, allowing
authentication bypass.
This is mitigated by the fact that by default, the well-known system
dbus-daemon (since 2003) and the well-known session dbus-daemon (in
stable releases since dbus 1.10.0 in 2015) only accept the EXTERNAL
authentication mechanism, and as a result will reject DBUS_COOKIE_SHA1
at an early stage, before manipulating cookies. As a result, this
vulnerability only applies to:
* system or session dbus-daemons with non-standard configuration
* third-party dbus-daemon invocations such as at-spi2-core (although
in practice at-spi2-core also only accepts EXTERNAL by default)
* third-party uses of DBusServer such as the one in Upstart
Avoiding symlink attacks in a portable way is difficult, because APIs
like openat() and Linux /proc/self/fd are not universally available.
However, because DBUS_COOKIE_SHA1 already doesn't work in practice for
a non-matching uid, we can solve this vulnerability in an easier way
without regressions, by rejecting it early (before looking at
~/.dbus-keyrings) whenever the requested identity doesn't match the
identity of the process hosting the DBusServer.
Change-Id: I04d70bf97d78d25551e9adc217a4dd7652d428b6
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/269
Closes: CVE-2019-12749
|
|
This reverts commit 662187a7597aaf9c9ad2a635944951e6174a36da.
We've optimized systemd-user without unified system/session.
So, we revert the patch for unified system/session.
Change-Id: I70ee37ebeda65e549c5f544d37d511cb6d54b757
|
|
Reconstruct rule with xml format.
Change-Id: I760f5c89f519672743a10fa15b66ac14b7e819a1
Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
|
|
print out connection log
Change-Id: Ib0fc3be8b07577da687a024f5c39178dad387644
Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
|
|
The bloom filters computing had been implemented in the past, basing
on systemd. However, the reimplementation introduced two bugs:
- no clearing of 'p' variable;
- clearing of hash_index variable in a wrong place.
This fixes the bugs.
The same applies to glib.
Change-Id: Ie7c602c6bc881e38c62f41d482ab3785b03c5503
|
|
This reverts commit c7fbfc743059b3e9988a359106ad459511b5ea78.
Change-Id: I86742a428f372ff6988a13df12694c550e2a53c2
|
|
fix Undefined Behavior Sanitizer error.
Change-Id: If3b68e68d4de753d0e66c0eeb07f626431057cbf
Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
|
|
Change-Id: I4e67ff2258b11bab764f51cfe7e2ae01f2a11d49
Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
|
|
|
|
The function defines and initializes local DBusError.
It is not used in kdbus_decode_msg() and function relies on assert for error.
So, remove the DBusError variable in kdbus_decode_msg().
Change-Id: Ic726f2a161f06766b081f1a98e83ff4f3834f75b
Signed-off-by: Himanshu Maithani <himanshu.m@samsung.com>
Signed-off-by: Gaurav Gupta <g.gupta@samsung.com>
|
|
Pass NULL as error argument to avoid setting error string in dbus_validate_bus_name(), thus avoid possible memory leak.
We expect the name to be valid bus name (utf8) as it is fetched from the connection.
It will also optimize stack usage as "local_error" variable & dbus_error_init() function are called in for loop.
Other fix could be to check free "error" if it is set.
Signed-off-by: Gaurav Gupta <g.gupta@samsung.com>
Reviewed-by: Himanshu Maithani <himanshu.m@samsung.com>
Change-Id: I773211edd76b6591369bbaae5464971894481a28
|
|
free message/name from the error in kdbus_write_msg_internal
Change-Id: I7f03abc0fc3f7c81e3725b3325f9e15209906e35
Signed-off-by: Himanshu Maithani <himanshu.m@samsung.com>
Signed-off-by: Gaurav Gupta <g.gupta@samsung.com>
|
|
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
We don't actually complete successful authentication, because that
would require us to generate a cookie and compute the correct SHA1,
which is difficult to do in a deterministic authentication script.
However, we do assert that dbus#269 (CVE-2019-12749) has been fixed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership
of a shared home directory by having the server write a secret "cookie"
into a .dbus-keyrings subdirectory of the desired identity's home
directory with 0700 permissions, and having the client prove that it can
read the cookie. This never actually worked for non-malicious clients in
the case where server uid != client uid (unless the server and client
both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional
Unix uid 0) because an unprivileged server would fail to write out the
cookie, and an unprivileged client would be unable to read the resulting
file owned by the server.
Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings
is owned by the uid of the server (a side-effect of a check added to
harden our use of XDG_RUNTIME_DIR), further ruling out successful use
by a non-malicious client with a uid differing from the server's.
Joe Vennix of Apple Information Security discovered that the
implementation of DBUS_COOKIE_SHA1 was susceptible to a symbolic link
attack: a malicious client with write access to its own home directory
could manipulate a ~/.dbus-keyrings symlink to cause the DBusServer to
read and write in unintended locations. In the worst case this could
result in the DBusServer reusing a cookie that is known to the
malicious client, and treating that cookie as evidence that a subsequent
client connection came from an attacker-chosen uid, allowing
authentication bypass.
This is mitigated by the fact that by default, the well-known system
dbus-daemon (since 2003) and the well-known session dbus-daemon (in
stable releases since dbus 1.10.0 in 2015) only accept the EXTERNAL
authentication mechanism, and as a result will reject DBUS_COOKIE_SHA1
at an early stage, before manipulating cookies. As a result, this
vulnerability only applies to:
* system or session dbus-daemons with non-standard configuration
* third-party dbus-daemon invocations such as at-spi2-core (although
in practice at-spi2-core also only accepts EXTERNAL by default)
* third-party uses of DBusServer such as the one in Upstart
Avoiding symlink attacks in a portable way is difficult, because APIs
like openat() and Linux /proc/self/fd are not universally available.
However, because DBUS_COOKIE_SHA1 already doesn't work in practice for
a non-matching uid, we can solve this vulnerability in an easier way
without regressions, by rejecting it early (before looking at
~/.dbus-keyrings) whenever the requested identity doesn't match the
identity of the process hosting the DBusServer.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/269
Closes: CVE-2019-12749
|