1. 17 Nov, 2015 1 commit
  2. 11 Nov, 2015 3 commits
  3. 05 Oct, 2015 1 commit
  4. 02 Oct, 2015 1 commit
    • Simon McVittie's avatar
      Cancel pending activation on any activation error · 694d63b6
      Simon McVittie authored
      This fixes the error reporting if you make two attempts
      to activate a service that cannot be activated due to an
      error that is reported synchronously, such as a system
      service with no User= line in its .service file.
      
      This is easy to reproduce with the gdbus(1) tool, which
      sends an Introspect call in addition to the one you asked
      it to. If you try to activate a service using
      
      gdbus call --session -d com.example.FailToActivate \
          -o / -m org.freedesktop.DBus.Peer.Ping
      
      then gdbus will actually send two method calls: one
      Introspect, and one Ping. The Introspect gets the correct
      error reply, but when dbus-daemon enters
      bus_activation_activate_service() for the Ping call, it
      sees that there is a pending activation and does an
      early-return. The pending activation does not finish
      until the timeout is reached.
      
      A couple of error cases handled this correctly, but the
      majority did not; make them all go into the same code path.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92200Reviewed-by: Thiago Macieira's avatarThiago Macieira <thiago@kde.org>
      694d63b6
  5. 14 May, 2015 1 commit
  6. 01 May, 2015 1 commit
  7. 04 Feb, 2015 1 commit
  8. 03 Feb, 2015 1 commit
  9. 18 Nov, 2014 1 commit
  10. 06 Nov, 2014 1 commit
  11. 09 Sep, 2014 1 commit
  12. 08 Sep, 2014 1 commit
  13. 05 Jun, 2014 1 commit
    • 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=78979Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Colin Walters's avatarColin Walters <walters@verbum.org>
      24c59070
  14. 12 Nov, 2013 1 commit
  15. 01 Nov, 2013 1 commit
  16. 09 Oct, 2013 1 commit
  17. 29 Aug, 2013 1 commit
  18. 28 Jun, 2013 1 commit
  19. 05 Jun, 2013 2 commits
    • Chengwei Yang's avatar
      When "activating" systemd, handle its special case better · b434238c
      Chengwei Yang authored
      When dbus-daemon receives a request to activate a systemd service before
      systemd has connected to it, it enqueues a fake request to "activate"
      systemd itself (as a way to get a BusPendingActivationEntry to track the
      process of waiting for systemd). When systemd later joins the bus,
      dbus-daemon sends the actual activation message; any future activation
      messages are sent directly to systemd.
      
      In the "pending" code path, the activation messages are currently
      dispatched as though they had been sent by the same process that sent
      the original activation request, which is wrong: the bus security
      policy probably doesn't allow that process to talk to systemd directly.
      They should be dispatched as though they had been sent by the
      dbus-daemon itself (connection == NULL), the same as in the non-pending
      code path.
      
      In the worst case, if the attempt to activate systemd timed out, the
      dbus-daemon would crash with a (fatal) warning, because in this special
      case, activation_message is a signal with no serial number, whereas the
      code to send an error reply is expecting a method call with a serial
      number.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199Signed-off-by: default avatarChengwei Yang <chengwei.yang@intel.com>
      Tested-by: default avatarMa Yu <yu.ma@intel.com>
      Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      b434238c
    • Chengwei Yang's avatar
      When "activating" systemd, handle its special case better · 8b3681e3
      Chengwei Yang authored
      When dbus-daemon receives a request to activate a systemd service before
      systemd has connected to it, it enqueues a fake request to "activate"
      systemd itself (as a way to get a BusPendingActivationEntry to track the
      process of waiting for systemd). When systemd later joins the bus,
      dbus-daemon sends the actual activation message; any future activation
      messages are sent directly to systemd.
      
      In the "pending" code path, the activation messages are currently
      dispatched as though they had been sent by the same process that sent
      the original activation request, which is wrong: the bus security
      policy probably doesn't allow that process to talk to systemd directly.
      They should be dispatched as though they had been sent by the
      dbus-daemon itself (connection == NULL), the same as in the non-pending
      code path.
      
      In the worst case, if the attempt to activate systemd timed out, the
      dbus-daemon would crash with a (fatal) warning, because in this special
      case, activation_message is a signal with no serial number, whereas the
      code to send an error reply is expecting a method call with a serial
      number.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199Signed-off-by: default avatarChengwei Yang <chengwei.yang@intel.com>
      Tested-by: default avatarMa Yu <yu.ma@intel.com>
      Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      8b3681e3
  20. 04 Jan, 2012 1 commit
    • Simon McVittie's avatar
      Revert all changes since a36d4918 · 5df8c3db
      Simon McVittie authored
      Someone seems to have merged part of master into 1.4. Again. Let's go
      back to the "last known good" point (the branch-point of some 1.4
      branches I had locally), then we can cherry-pick the changes that
      should have gone in.
      5df8c3db
  21. 21 Sep, 2011 3 commits
  22. 19 Sep, 2011 1 commit
  23. 05 Aug, 2011 1 commit
  24. 13 Jun, 2011 4 commits
  25. 26 Apr, 2011 1 commit
  26. 08 Apr, 2011 1 commit
  27. 16 Feb, 2011 6 commits