1. 30 Jan, 2015 3 commits
  2. 29 Jan, 2015 1 commit
  3. 27 Jan, 2015 2 commits
  4. 06 Jan, 2015 4 commits
  5. 05 Jan, 2015 8 commits
  6. 01 Jan, 2015 6 commits
    • Simon McVittie's avatar
      Merge branch 'dbus-1.8' and prepare 1.9.6 · ae9d7149
      Simon McVittie authored
    • Simon McVittie's avatar
      Prepare release for Monday · abbbf449
      Simon McVittie authored
    • Simon McVittie's avatar
      Hardening: only accept Stats function calls at the canonical object path · eec885de
      Simon McVittie authored
      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
      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's avatarThiago Macieira <thiago@kde.org>
      [added missing #include; extended commit message -smcv]
    • Simon McVittie's avatar
    • Simon McVittie's avatar
      Hardening: only allow the uid of the dbus-daemon to call UpdateActivationEnvironment · a67cb9bf
      Simon McVittie authored
      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's avatarThiago Macieira <thiago@kde.org>
      [adjusted commit message -smcv]
    • Simon McVittie's avatar
      Hardening: reject UpdateActivationEnvironment on non-canonical path · 6a3f563a
      Simon McVittie authored
      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
      and only allow ("/org/freedesktop/DBus",
      We deliberately continue to provide read-only APIs like
      GetConnectionUnixUser at all object paths, for backwards compatibility.
      Reviewed-by: Thiago Macieira's avatarThiago Macieira <thiago@kde.org>
      [adjusted commit message to note that this is probably only DoS -smcv]
  7. 23 Dec, 2014 1 commit
  8. 24 Nov, 2014 8 commits
  9. 22 Nov, 2014 2 commits
    • Simon McVittie's avatar
      Revert "config: change default auth_timeout to 5 seconds" · 02e1ddf9
      Simon McVittie authored
      This reverts commit 54d26df5.
      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:
            <limit name="auth_timeout">5000</limit>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86431
    • Simon McVittie's avatar
      Log to syslog when auth_timeout drops an incomplete connection · 29c64424
      Simon McVittie authored
      This is a symptom of either a denial of service attack, or a
      serious performance problem. Either way, sysadmins should know.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86431
  10. 18 Nov, 2014 2 commits
  11. 14 Nov, 2014 3 commits