1. 03 Dec, 2018 1 commit
  2. 14 Nov, 2017 1 commit
  3. 25 Sep, 2017 1 commit
  4. 21 Feb, 2017 2 commits
  5. 20 Feb, 2017 2 commits
  6. 16 Feb, 2017 1 commit
  7. 28 Nov, 2016 2 commits
    • Simon McVittie's avatar
      Mediate auto-activation attempts through AppArmor · dc25979e
      Simon McVittie authored
      Because the recipient process is not yet available, we have to make some
      assumption about its AppArmor profile. Parsing the first word of
      the Exec value and then chasing symlinks seems like too much magic,
      so I've gone for something more explicit. If the .service file contains
      
      AssumedAppArmorLabel=/foo/bar
      
      then we will do the AppArmor query on the assumption that the recipient
      AppArmor label will be as stated. Otherwise, we will do a query
      with an unspecified label, which means that AppArmor rules that do
      specify a peer label will never match it.
      
      Regardless of the result of this query, we will do an independent
      AppArmor query when the activation has actually happened, this time
      with the correct peer label; that second query will still be used
      to decide whether to deliver the message. As a result, if this change
      has any effect, it is to make the bus more restrictive; it does not
      allow anything that would previously have been denied.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <philip.withnall@collabora.co.uk>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
      dc25979e
    • Simon McVittie's avatar
      Do not auto-activate services if we could not send a message · 373cc47c
      Simon McVittie authored
      We specifically do not check recipient policies, because
      the recipient policy is based on properties of the
      recipient process (in particular, its uid), which we do
      not necessarily know until we have already started it.
      
      In this initial implementation we do not check LSMs either,
      because we cannot know what LSM context the recipient process
      is going to have. However, LSM support will need to be added
      to make this feature useful, because StartServiceByName is
      normally allowed in non-LSM environments, and is more
      powerful than auto-activation anyway.
      
      The StartServiceByName method does not go through this check,
      because if access to that method has been granted, then
      it's somewhat obvious that you can start arbitrary services.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <philip.withnall@collabora.co.uk>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
      373cc47c
  8. 10 Oct, 2016 2 commits
    • Simon McVittie's avatar
      dbus_activation_systemd_failure: do not use non-literal format string · e473ab85
      Simon McVittie authored
      In principle this could lead to arbitrary memory overwrite via
      a format string attack in the message received from systemd,
      resulting in arbitrary code execution.
      
      This is not believed to be an exploitable security vulnerability on the
      system bus in practice: it can only be exploited by the owner of the
      org.freedesktop.systemd1 bus name, which is restricted to uid 0, so
      if systemd is attacker-controlled then the system is already doomed.
      Similarly, if a systemd system unit mentioned in the activation failure
      message has an attacker-controlled name, then the attacker likely already
      has sufficient access to execute arbitrary code as root in any case.
      
      However, prior to dbus 1.8.16 and 1.9.10, due to a missing check for
      systemd's identity, unprivileged processes could forge activation
      failure messages which would have gone through this code path.
      We thought at the time that this was a denial of service vulnerability
      (CVE-2015-0245); this bug means that it was in fact potentially an
      arbitrary code execution vulnerability.
      
      Bug found using -Wsuggest-attribute=format and -Wformat-security.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Colin Walters's avatarColin Walters <walters@verbum.org>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98157
      e473ab85
    • Simon McVittie's avatar
      dbus_activation_systemd_failure: do not use non-literal format string · 91ec6a05
      Simon McVittie authored
      In principle this could lead to arbitrary memory overwrite via
      a format string attack in the message received from systemd,
      resulting in arbitrary code execution.
      
      This is not believed to be an exploitable security vulnerability on the
      system bus in practice: it can only be exploited by the owner of the
      org.freedesktop.systemd1 bus name, which is restricted to uid 0, so
      if systemd is attacker-controlled then the system is already doomed.
      Similarly, if a systemd system unit mentioned in the activation failure
      message has an attacker-controlled name, then the attacker likely already
      has sufficient access to execute arbitrary code as root in any case.
      
      However, prior to dbus 1.8.16 and 1.9.10, due to a missing check for
      systemd's identity, unprivileged processes could forge activation
      failure messages which would have gone through this code path.
      We thought at the time that this was a denial of service vulnerability
      (CVE-2015-0245); this bug means that it was in fact potentially an
      arbitrary code execution vulnerability.
      
      Bug found using -Wsuggest-attribute=format and -Wformat-security.
      Signed-off-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Colin Walters's avatarColin Walters <walters@verbum.org>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98157
      91ec6a05
  9. 05 Oct, 2016 1 commit
  10. 30 Sep, 2016 1 commit
  11. 16 Aug, 2016 2 commits
  12. 12 Feb, 2016 2 commits
  13. 11 Feb, 2016 1 commit
  14. 02 Dec, 2015 1 commit
    • Simon McVittie's avatar
      Do not require systemd to have a service file if using it for activation · 31eccce8
      Simon McVittie authored
      With --systemd-activation we special-case the name
      org.freedesktop.systemd1 by assuming that it will eventually connect
      to the bus. With that in mind, we can ignore whether it has a
      .service file, and let it be "activated" regardless.
      
      This fixes a regression test failure on non-systemd systems such
      as the Ubuntu 14.04 OS on travis-ci.org: UpdateActivationEnvironment
      failed, because it tried to update the (fake) systemd environment,
      but because systemd was not actually installed, there was no
      service file for it in the system's search paths. We could address this
      by placing a dummy service file with Exec=/bin/false in our search path
      like the real systemd does, but it seems cleaner to not require this;
      this would eventually enable the real systemd to stop installing
      that dummy service file.
      
      This would not happen outside the regression tests, because there is
      no sense in using --systemd-activation without systemd installed.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      31eccce8
  15. 01 Dec, 2015 1 commit
    • Simon McVittie's avatar
      Do not require systemd to have a service file if using it for activation · 3c602d6d
      Simon McVittie authored
      With --systemd-activation we special-case the name
      org.freedesktop.systemd1 by assuming that it will eventually connect
      to the bus. With that in mind, we can ignore whether it has a
      .service file, and let it be "activated" regardless.
      
      This fixes a regression test failure on non-systemd systems such
      as the Ubuntu 14.04 OS on travis-ci.org: UpdateActivationEnvironment
      failed, because it tried to update the (fake) systemd environment,
      but because systemd was not actually installed, there was no
      service file for it in the system's search paths. We could address this
      by placing a dummy service file with Exec=/bin/false in our search path
      like the real systemd does, but it seems cleaner to not require this;
      this would eventually enable the real systemd to stop installing
      that dummy service file.
      
      This would not happen outside the regression tests, because there is
      no sense in using --systemd-activation without systemd installed.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93194Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      3c602d6d
  16. 17 Nov, 2015 1 commit
  17. 11 Nov, 2015 3 commits
  18. 05 Oct, 2015 1 commit
  19. 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
  20. 14 May, 2015 1 commit
  21. 01 May, 2015 1 commit
  22. 04 Feb, 2015 1 commit
  23. 03 Feb, 2015 1 commit
  24. 18 Nov, 2014 1 commit
  25. 06 Nov, 2014 1 commit
  26. 09 Sep, 2014 1 commit
  27. 08 Sep, 2014 1 commit
  28. 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
  29. 12 Nov, 2013 1 commit
  30. 01 Nov, 2013 1 commit
  31. 09 Oct, 2013 1 commit
  32. 29 Aug, 2013 1 commit