1. 17 Jun, 2015 3 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>
      fb5076b7
    • Colin Walters's avatar
      CVE-2015-4625: Bind use of cookies to specific uids · 493aa5dc
      Colin Walters authored
      http://lists.freedesktop.org/archives/polkit-devel/2015-June/000425.html
      
      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>
      493aa5dc
    • Colin Walters's avatar
      CVE-2015-4625: Use unpredictable cookie values, keep them secret · ea544ffc
      Colin Walters authored
      Tavis noted that it'd be possible with a 32 bit counter for someone to
      cause the cookie to wrap by creating Authentication requests in a
      loop.
      
      Something important to note here is that wrapping of signed integers
      is undefined behavior in C, so we definitely want to fix that.  All
      counter integers used in this patch are unsigned.
      
      See the comment above `authentication_agent_generate_cookie` for
      details, but basically we're now using a cookie of the form:
      
      ```
              <agent serial> - <agent random id> - <session serial> - <session
      random id>
      ```
      
      Which has multiple 64 bit counters, plus unpredictable random 128 bit
      integer ids (effectively UUIDs, but we're not calling them that
      because we don't need to be globally unique.
      
      We further ensure that the cookies are not visible to other processes
      by changing the setuid helper to accept them over standard input.  This
      means that an attacker would have to guess both ids.
      
      In any case, the security hole here is better fixed with the other
      change to bind user id (uid) of the agent with cookie lookups, making
      cookie guessing worthless.
      
      Nevertheless, I think it's worth doing this change too, for defense in
      depth.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90832
      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>
      ea544ffc
  2. 10 Jun, 2015 1 commit
  3. 08 Jun, 2015 5 commits
  4. 05 Jun, 2015 2 commits
  5. 03 Jun, 2015 6 commits
  6. 31 Mar, 2015 1 commit
  7. 12 Jan, 2015 1 commit
  8. 27 Aug, 2014 1 commit
  9. 03 Jun, 2014 1 commit
  10. 22 Apr, 2014 1 commit
  11. 19 Feb, 2014 1 commit
  12. 18 Feb, 2014 1 commit
  13. 09 Feb, 2014 1 commit
    • Rui Tiago Matos's avatar
      PolkitAgentSession: fix race between child and io watches · 7650ad1e
      Rui Tiago Matos authored
      The helper flushes and fdatasyncs stdout and stderr before terminating
      but this doesn't guarantee that our io watch is called before our
      child watch. This means that we can end up with a successful return
      from the helper which we still report as a failure.
      
      If we add G_IO_HUP and G_IO_ERR to the conditions we look for in the
      io watch and the child terminates we still run the io watch handler
      which will complete the session.
      
      This means that the child watch is in fact needless and we can remove
      it.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=60847
      7650ad1e
  14. 07 Dec, 2013 1 commit
  15. 22 Nov, 2013 1 commit
  16. 11 Nov, 2013 6 commits
  17. 09 Nov, 2013 1 commit
  18. 07 Nov, 2013 1 commit
  19. 18 Sep, 2013 4 commits
  20. 04 Jun, 2013 1 commit