1. 22 Jan, 2020 1 commit
  2. 22 Oct, 2019 1 commit
    • Laurent Bigonville's avatar
      Stop using selinux_set_mapping() function · 6072f8b2
      Laurent Bigonville authored
      Currently, if the "dbus" security class or the associated AV doesn't
      exist, dbus-daemon fails to initialize and exits immediately. Also the
      security classes or access vector cannot be reordered in the policy.
      This can be a problem for people developing their own policy or trying
      to access a machine where, for some reasons, there is not policy defined
      at all.
      The code here copy the behaviour of the selinux_check_access() function.
      We cannot use this function here as it doesn't allow us to define the
      AVC entry reference.
      See the discussion at https://marc.info/?l=selinux&m=152163374332372&w=2
      Resolves: dbus/dbus#198
  3. 23 Sep, 2019 2 commits
  4. 19 Aug, 2019 1 commit
  5. 13 Aug, 2019 1 commit
  6. 15 Jul, 2019 2 commits
  7. 03 Jul, 2019 17 commits
  8. 02 Jul, 2019 6 commits
  9. 14 Jun, 2019 1 commit
  10. 11 Jun, 2019 2 commits
  11. 09 Jun, 2019 4 commits
    • Simon McVittie's avatar
      Prepare version 1.13.12 · df9dabe5
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      test: Add basic test coverage for DBUS_COOKIE_SHA1 · 6231e7d7
      Simon McVittie authored
      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 #269
       (CVE-2019-12749) has been fixed.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      auth: Reject DBUS_COOKIE_SHA1 for users other than the server owner · 2a11ab9b
      Simon McVittie authored
      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's avatarSimon McVittie <smcv@collabora.com>
      Closes: #269
      Closes: CVE-2019-12749
    • Simon McVittie's avatar
      Revert "Start spec 0.36 development" · 00099d5d
      Simon McVittie authored
      This reverts commit edece027.
      No spec changes have happened since 0.35.
  12. 31 May, 2019 1 commit
  13. 30 May, 2019 1 commit