1. 15 Sep, 2014 1 commit
  2. 12 Sep, 2014 2 commits
  3. 07 Sep, 2014 1 commit
  4. 05 Sep, 2014 1 commit
  5. 04 Sep, 2014 1 commit
  6. 02 Jul, 2014 1 commit
  7. 30 Jun, 2014 3 commits
  8. 11 Jun, 2014 2 commits
  9. 10 Jun, 2014 1 commit
  10. 05 Jun, 2014 2 commits
    • Simon McVittie's avatar
      Prepare embargoed security release · c3650785
      Simon McVittie authored
    • Alban Crequy's avatar
      CVE-2014-3477: deliver activation errors correctly, fixing Denial of Service · 24c59070
      Alban Crequy authored
      How it should work:
      When a D-Bus message activates a service, LSMs (SELinux or AppArmor) check
      whether the message can be delivered after the service has been activated. The
      service is considered activated when its well-known name is requested with
      org.freedesktop.DBus.RequestName. When the message delivery is denied, the
      service stays activated but should not receive the activating message (the
      message which triggered the activation). dbus-daemon is supposed to drop the
      activating message and reply to the sender with a D-Bus error message.
      However, it does not work as expected:
      1. The error message is delivered to the service instead of being delivered to
         the sender. As an example, the error message could be something like:
           An SELinux policy prevents this sender from sending this
           message to this recipient, [...] member="MaliciousMethod"
         If the sender and the service are malicious confederates and agree on a
         protocol to insert information in the member name, the sender can leak
         information to the service, even though the LSM attempted to block the
         communication between the sender and the service.
      2. The error message is delivered as a reply to the RequestName call from
         service. It means the activated service will believe it cannot request the
         name and might exit. The sender could activate the service frequently and
         systemd will give up activating it. Thus the denial of service.
      The following changes fix the bug:
      - bus_activation_send_pending_auto_activation_messages() only returns an error
        in case of OOM. The prototype is changed to return TRUE, or FALSE on OOM
        (and its only caller sets the OOM error).
      - When a client is not allowed to talk to the service, a D-Bus error message
        is pre-allocated to be delivered to the client as part of the transaction.
        The error is not propagated to the caller so RequestName will not fail
        (except on OOM).
      [fixed a misleading comment -smcv]
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78979
      Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Colin Walters's avatarColin Walters <walters@verbum.org>
  11. 30 Apr, 2014 5 commits
    • Simon McVittie's avatar
      development version · 41689832
      Simon McVittie authored
    • Simon McVittie's avatar
      1.8.2 · 789800af
      Simon McVittie authored
    • LRN's avatar
      Handle 0x0d0a EOLs in spawn_dbus_daemon() · 28812c88
      LRN authored
      On W32 dbus daemon will print output in text mode, with 0x0d0a EOLs instead
      of just 0x0a. Be able to handle that.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=75863
      Reviewed-by: Simon McVittie
    • Simon McVittie's avatar
      NEWS · c02ac705
      Simon McVittie authored
    • Роман Донченко's avatar
      Avoid killing all available processes if an X error arrives early on · 3be60637
      Роман Донченко authored
      The timeline of events in dbus-launch's main process goes something like this:
      * do initial X calls
      * do some other stuff
      * fork
          (child process starts doing some other stuff)
      * return "intermediate parent" pid from fork()
      * obtain bus daemon pid from bus_pid_to_launcher_pipe
      * do things that might include X11 calls or killing the dbus-daemon
      Meanwhile, the "babysitter" child goes like this:
      * return 0 from fork()
      * obtain bus daemon pid from parent process via bus_pid_to_babysitter_pipe
      * do things that might include X11 calls or killing the bus daemon
      Before [1] or [3], the right thing to do about an X error is to just
      exit. The current implementation called kill(-1) first, which is
      undesirable: it kills unrelated processes. With this change, we
      just exit.
      After [2] or [4], the right thing to do is to kill the dbus-daemon,
      and that's what the existing code did.
      Between [1] and [2], or between [3] and [4], there is no correct thing
      that we can do immediately: we would have to wait for the end of the
      "critical section", *then* kill the dbus-daemon. This has not yet been
      implemented, so this patch relies for its correctness on the fact that
      there are no libX11 calls between those points, so we cannot receive
      an X error between them.
      dbus-launch deserves more comments, or a reimplementation that is easier to
      understand, but this change is certainly better than nothing.
      [Commit message added, summarizing reviewers' comments -smcv]
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=74698
      Reviewed-by: Simon McVittie
      Reviewed-by: Thiago Macieira
  12. 28 Apr, 2014 4 commits
  13. 13 Mar, 2014 1 commit
  14. 06 Mar, 2014 1 commit
  15. 03 Mar, 2014 1 commit
  16. 27 Jan, 2014 1 commit
  17. 21 Jan, 2014 1 commit
  18. 20 Jan, 2014 3 commits
  19. 17 Jan, 2014 8 commits