1. 06 Oct, 2015 1 commit
  2. 04 Oct, 2015 1 commit
  3. 01 Oct, 2015 1 commit
  4. 28 Aug, 2015 1 commit
  5. 20 Jul, 2015 2 commits
  6. 02 Jul, 2015 2 commits
  7. 23 Jun, 2015 3 commits
  8. 19 Jun, 2015 5 commits
  9. 18 Jun, 2015 5 commits
  10. 17 Jun, 2015 3 commits
    • Miloslav Trmač's avatar
      docs: Update for changes to uid binding/AuthenticationAgentResponse2 · fb5076b7
      Miloslav Trmač authored and Colin Walters's avatar Colin Walters committed
       - 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=90837
      
      Reviewed-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 and Colin Walters's avatar Colin Walters committed
      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 and Colin Walters's avatar Colin Walters committed
      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
  11. 10 Jun, 2015 1 commit
  12. 08 Jun, 2015 5 commits
  13. 05 Jun, 2015 2 commits
  14. 03 Jun, 2015 6 commits
  15. 31 Mar, 2015 1 commit
  16. 12 Jan, 2015 1 commit