1. 06 Nov, 2018 1 commit
  2. 03 Jul, 2018 1 commit
    • Miloslav Trmač's avatar
      Fix CVE-2018-1116: Trusting client-supplied UID · bc7ffad5
      Miloslav Trmač authored
      As part of CVE-2013-4288, the D-Bus clients were allowed (and
      encouraged) to submit the UID of the subject of authorization checks
      to avoid races against UID changes (notably using executables
      set-UID to root).
      However, that also allowed any client to submit an arbitrary UID, and
      that could be used to bypass "can only ask about / affect the same UID"
      checks in CheckAuthorization / RegisterAuthenticationAgent /
      UnregisterAuthenticationAgent.  This allowed an attacker:
      - With CheckAuthorization, to cause the registered authentication
        agent in victim's session to pop up a dialog, or to determine whether
        the victim currently has a temporary authorization to perform an
        (In principle, the attacker can also determine whether JavaScript
        rules allow the victim process to perform an operation; however,
        usually rules base their decisions on information determined from
        the supplied UID, so the attacker usually won't learn anything new.)
      - With RegisterAuthenticationAgent, to prevent the victim's
        authentication agent to work (for a specific victim process),
        or to learn about which operations requiring authorization
        the victim is attempting.
      To fix this, expose internal _polkit_unix_process_get_owner() /
      obsolete polkit_unix_process_get_owner() as a private
      polkit_unix_process_get_racy_uid__() (being more explicit about the
      dangers on relying on it), and use it in
      polkit_backend_session_monitor_get_user_for_subject() to return
      a boolean indicating whether the subject UID may be caller-chosen.
      Then, in the permission checks that require the subject to be
      equal to the caller, fail on caller-chosen UIDs (and continue
      through the pre-existing code paths which allow root, or root-designated
      server processes, to ask about arbitrary subjects.)
      Signed-off-by: default avatarMiloslav Trmač <mitr@redhat.com>
  3. 03 Apr, 2018 4 commits
  4. 04 Apr, 2017 1 commit
  5. 12 Dec, 2016 1 commit
    • Colin Walters's avatar
      build: Pull in GCC warning infra from ostree · 3272a988
      Colin Walters authored
      I'm trying to keep a relatively standard set around, and the code
      there is cleaner than what we had before.
      Also, injecting as WARN_CFLAGS rather than changing CFLAGS during
      autoconf avoids any surprises from new warnings breaking autoconf
  6. 05 May, 2016 1 commit
  7. 01 Oct, 2015 1 commit
  8. 20 Jul, 2015 1 commit
  9. 17 Jun, 2015 2 commits
    • Miloslav Trmač's avatar
      docs: Update for changes to uid binding/AuthenticationAgentResponse2 · fb5076b7
      Miloslav Trmač authored
       - Refer to PolkitAgentSession in general instead of to _response only
       - Revert to the original description of authentication cancellation, the
         agent really needs to return an error to the caller (in addition to dealing
         with the session if any).
       - Explicitly document the UID assumption; in the process fixing bug #69980.
       - Keep documenting that we need a sufficiently privileged caller.
       - Refer to the ...Response2 API in more places.
       - Also update docbook documentation.
       - Drop a paragraph suggesting non-PolkitAgentSession implementations are
         expected and commonplace.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90837Reviewed-by: Colin Walters's avatarColin Walters <walters@redhat.com>
    • Colin Walters's avatar
      CVE-2015-4625: Bind use of cookies to specific uids · 493aa5dc
      Colin Walters authored
      The "cookie" value that Polkit hands out is global to all polkit
      users.  And when `AuthenticationAgentResponse` is invoked, we
      previously only received the cookie and *target* identity, and
      attempted to find an agent from that.
      The problem is that the current cookie is just an integer
      counter, and if it overflowed, it would be possible for
      an successful authorization in one session to trigger a response
      in another session.
      The overflow and ability to guess the cookie were fixed by the
      previous patch.
      This patch is conceptually further hardening on top of that.  Polkit
      currently treats uids as equivalent from a security domain
      perspective; there is no support for
      SELinux/AppArmor/etc. differentiation.
      We can retrieve the uid from `getuid()` in the setuid helper, which
      allows us to ensure the uid invoking `AuthenticationAgentResponse2`
      matches that of the agent.
      Then the authority only looks at authentication sessions matching the
      cookie that were created by a matching uid, thus removing the ability
      for different uids to interfere with each other entirely.
      Several fixes to this patch were contributed by:
      Miloslav Trmač <mitr@redhat.com>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90837
      CVE: CVE-2015-4625
      Reported-by: default avatarTavis Ormandy <taviso@google.com>
      Reviewed-by: default avatarMiloslav Trmač <mitr@redhat.com>
      Signed-off-by: Colin Walters's avatarColin Walters <walters@redhat.com>
  10. 08 Jun, 2015 2 commits
  11. 03 Jun, 2015 1 commit
  12. 31 Mar, 2015 1 commit
  13. 12 Jan, 2015 1 commit
  14. 11 Nov, 2013 3 commits
    • Colin Walters's avatar
      Use G_GNUC_BEGIN_IGNORE_DEPRECATIONS to avoid warning spam · a4f1c2a5
      Colin Walters authored
      In these cases, we can't every drop use of our API which we deprecated
      for external callers; for example where a (deprecated) command line is
      invoking the deprecated API.
      This patch avoids having polkit developers get spammed by unfixable
    • Colin Walters's avatar
      Port internals non-deprecated PolkitProcess API where possible · 6d3d0a8f
      Colin Walters authored
      We can't port everything, but in PolkitPermission and these test
      cases, we can use _for_owner() with the right information.
    • Colin Walters's avatar
      PolkitSystemBusName: Retrieve both pid and uid · bfa5036b
      Colin Walters authored
      For polkit_system_bus_name_get_process_sync(), as pointed out by
      Miloslav Trmac, we can securely retrieve the owner uid as well from
      the system bus, rather than (racily) looking it up internally.
      This avoids use of a deprecated API.
      However, this is not a security fix because nothing in the polkit
      codebase itself actually retrieves the uid from the result of this API
      call.  But, it might be useful in the future.
  15. 07 Nov, 2013 1 commit
  16. 18 Sep, 2013 1 commit
    • Colin Walters's avatar
      polkitunixprocess: Deprecate racy APIs · 08291789
      Colin Walters authored
      It's only safe for processes to be created with their owning uid,
      (without kernel support, which we don't have).  Anything else is
      subject to clients exec()ing setuid binaries after the fact.
  17. 29 May, 2013 1 commit
  18. 18 Apr, 2013 1 commit
  19. 15 Apr, 2013 5 commits
  20. 13 Nov, 2012 1 commit
  21. 23 May, 2012 2 commits
  22. 12 Apr, 2012 1 commit
  23. 06 Feb, 2012 2 commits
  24. 10 Jan, 2012 1 commit
  25. 03 Jan, 2012 1 commit
  26. 22 Dec, 2011 1 commit
  27. 01 Aug, 2011 1 commit