summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-06-02sysdeps-unix: On MSG_CTRUNC, close the fds we did receiveSimon McVittie1-12/+20
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
2020-06-01bus/policy: use hash tables for checking policysubmit/tizen/20200601.123056accepted/tizen/unified/20200602.133244Adrian Szyndela2-14/+322
Only for send/receive/own rules in default context. Change-Id: Iabbbfa5d582f9993b832f49193da93225c645014
2020-06-01bus/connection: API for getting list of names from connectionsAdrian Szyndela2-0/+10
Change-Id: I2854f6cc51b26ff04a9984778f899ba9656ba290
2020-06-01bus/policy: direct checking of policy, without copiesAdrian Szyndela1-166/+95
Change-Id: I42926c107aae0be1a1247a61f3558122b07f9914
2020-06-01bus/policy: generalized policy checking processAdrian Szyndela1-135/+135
Change-Id: I573ddbc7e64bef38ed7517644bd842728e14679b
2020-06-01bus/policy: reduce warnings by adding default casesAdrian Szyndela1-0/+8
Change-Id: I6267b3c7cc6fead8c4dd37967c122e1597239ebf
2020-06-01bus/policy: reduce number of params in check_ functionsAdrian Szyndela1-60/+76
No functional changes, just packed arguments to structs. Change-Id: I0e5a22a208ba7085727e617c52cd061c39524967
2020-06-01bus/policy: extract check_* functionsAdrian Szyndela1-444/+485
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
2020-06-01bus/policy: remove optimizationAdrian Szyndela1-106/+0
This removes optimization, because in subsequent commits we're going to apply: * direct checking of policy * hash tables instead of lists. Change-Id: I6de32c4a29bac1d185f76eb88b22198c9ea22413
2020-06-01bus/policy: make local functions staticAdrian Szyndela2-7/+9
Change-Id: Ideba1fea470bc0d38c04f428b23270fe6176ac95
2020-05-22Stats: Add field PendingRepliessanghyeok.oh3-1/+54
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>
2020-05-19Coverity fixsanghyeok.oh1-3/+8
Change-Id: I57c318bdf8a0e2d8d731c002185946930392718e
2020-05-15Update NEWSSimon McVittie1-0/+4
Signed-off-by: Simon McVittie <smcv@collabora.com>
2020-05-15dbus-daemon test: Don't test fd limits if in an unprivileged containerSimon McVittie1-2/+28
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
2020-04-20Update NEWSSimon McVittie1-0/+3
2020-04-20doxygen: fix example for dbus_message_append_argsFelipe Franciosi1-4/+10
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>
2020-04-20Update NEWSSimon McVittie1-0/+11
2020-04-20cmake: Add X11 include path for toolsTuomo Rinne1-0/+1
Fixes compilation issues for case when X11 is not in a standard location
2020-04-20doc: replace dbus-send's --address with --peer and --busChristopher Morin1-3/+9
See merge request dbus/dbus!115 (cherry picked from commit fd41caa3664d480605628f08c217581bc42fa3e7)
2020-04-20Update NEWSSimon McVittie1-1/+4
2020-04-20dbus-message: bring back the original layout of DBusMessageItersubmit/tizen/20200420.213220submit/tizen/20200420.123023accepted/tizen/unified/20200421.051607Adrian Szyndela2-99/+96
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
2020-04-20spec: fix dbus.conf paths in files sectionAdrian Szyndela1-2/+2
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
2020-04-16Merge dbus-1.12.16 into tizensubmit/tizen/20200417.133959Adrian Szyndela277-7241/+17628
Change-Id: Ie55319b9a3075a1f1f12afadecc6c06c39e3dd3b
2020-04-16activation: fix indentationupgrade-to-1.12.16Adrian Szyndela1-1/+1
2020-04-16dbus-transport: stop using orig_len outside its contextAdrian Szyndela1-1/+1
2020-04-16packaging: update packaging for dbus-1.12.16Adrian Szyndela2-8/+10
- 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
2020-04-16Merge dbus-1.12.16 into tizenAdrian Szyndela275-7232/+17617
dbus 1.12.16
2020-03-30Revert "Add dependency to security-manager.socket"submit/tizen/20200402.112144accepted/tizen/unified/20200406.133221INSUN PYO1-2/+0
This reverts commit 8d7fa32af68f2ba1f5da3494ce6d50e8e7c2c034. Change-Id: Iaf3890e804b87b7c6751237e0ef93b3ad5db9ceb
2020-03-25Revert "Remove DefaultDependencies=no from dbus.socket"INSUN PYO1-0/+1
This reverts commit 873bad7e9515fbafb8682fa6cdadfee629762e0d. Change-Id: I642e8ca08d551320b56d97e682c969689640700f
2020-03-12policy: print policy denied complaint log for signal broadcastingsanghyeok.oh1-2/+4
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
2020-02-25Merge branch 'cherry-pick-b034b83b' into 'dbus-1.12'Simon McVittie1-3/+4
[1.12] bus: Don't explicitly clear BusConnections.monitors See merge request dbus/dbus!142
2020-02-25bus: Don't explicitly clear BusConnections.monitorsSimon McVittie1-3/+4
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)
2020-02-20Merge branch 'cherry-pick-bf71a58e' into 'dbus-1.12'Simon McVittie1-1/+1
doc: Fix environment variable name in dbus-daemon(1) See merge request dbus/dbus!141
2020-02-20doc: Fix environment variable name in dbus-daemon(1)Philip Withnall1-1/+1
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)
2020-01-13auth: Reject DBUS_COOKIE_SHA1 for users other than the server ownerSimon McVittie1-0/+30
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
2019-08-20Revert "tizen: Add additional unit for "unified" user session"tizen_5.5.m2_releasesubmit/tizen_5.5_mobile_hotfix/20201026.185106submit/tizen_5.5/20191031.000006submit/tizen/20190820.090809accepted/tizen/unified/20190822.045457accepted/tizen/5.5/unified/mobile/hotfix/20201027.063100accepted/tizen/5.5/unified/20191031.005930tizen_5.5_tvtizen_5.5_mobile_hotfixaccepted/tizen_5.5_unified_mobile_hotfixYunmi Ha5-43/+1
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
2019-07-30policy: modify complaint log to print out matched rulesubmit/tizen/20190812.022819accepted/tizen/unified/20190816.112439sanghyeok.oh4-16/+132
Reconstruct rule with xml format. Change-Id: I760f5c89f519672743a10fa15b66ac14b7e819a1 Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
2019-07-23policy: change complaint log format of bus_client_policy_check_can_own() to ↵sanghyeok.oh1-5/+9
print out connection log Change-Id: Ib0fc3be8b07577da687a024f5c39178dad387644 Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
2019-07-19kdbus: fix computing bloom filterssubmit/tizen/20190719.104741accepted/tizen/unified/20190722.074825Adrian Szyndela1-3/+3
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
2019-07-17Revert "Fix for smack error when dbus-daemon(session) accesses proc/cmdline"submit/tizen/20190717.061730accepted/tizen/unified/20190717.220434Hyotaek Shim1-1/+1
This reverts commit c7fbfc743059b3e9988a359106ad459511b5ea78. Change-Id: I86742a428f372ff6988a13df12694c550e2a53c2
2019-07-01gvariant: fix UBSan related codesubmit/tizen/20190701.095512accepted/tizen/unified/20190702.114943sanghyeok.oh1-2/+2
fix Undefined Behavior Sanitizer error. Change-Id: If3b68e68d4de753d0e66c0eeb07f626431057cbf Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
2019-06-26policy: add complaint log for bus_client_policy_check_can_own()sanghyeok.oh1-0/+5
Change-Id: I4e67ff2258b11bab764f51cfe7e2ae01f2a11d49 Signed-off-by: sanghyeok.oh <sanghyeok.oh@samsung.com>
2019-06-24Merge "Remove unused DbusError to avoid memory leak." into tizensubmit/tizen/20190624.005319accepted/tizen/unified/20190624.115337sanghyeok oh1-3/+1
2019-06-17remove unused DBusError in kdbus_read_message()Himanshu Maithani1-6/+2
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>
2019-06-13Remove unused DbusError to avoid memory leak.Gaurav Gupta1-3/+1
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
2019-06-12fix: missing dbus_error_free in kdbus_write_msg_internalsubmit/tizen/20190624.001018himanshu.m@samsung.com1-0/+1
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>
2019-06-11Start 1.12.18 developmentSimon McVittie2-1/+6
Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-06-09Prepare version 1.12.16dbus-1.12.16Simon McVittie2-4/+17
Signed-off-by: Simon McVittie <smcv@collabora.com>
2019-06-09test: Add basic test coverage for DBUS_COOKIE_SHA1Simon McVittie7-3/+184
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>
2019-06-09auth: Reject DBUS_COOKIE_SHA1 for users other than the server ownerSimon McVittie1-0/+32
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