1. 07 Feb, 2018 1 commit
  2. 18 May, 2017 1 commit
  3. 06 Mar, 2017 1 commit
  4. 19 Jan, 2017 1 commit
  5. 05 Dec, 2016 1 commit
    • Josh Stone's avatar
      Yama: allow access for the current ptrace parent · 50523a29
      Josh Stone authored
      Under ptrace_scope=1, it's possible to have a tracee that is already
      ptrace-attached, but is no longer a direct descendant.  For instance, a
      forking daemon will be re-parented to init, losing its ancestry to the
      tracer that launched it.
      
      The tracer can continue using ptrace in that state, but it will be
      denied other accesses that check PTRACE_MODE_ATTACH, like process_vm_rw
      and various procfs files.  There's no reason to prevent such access for
      a tracer that already has ptrace control anyway.
      
      This patch adds a case to ptracer_exception_found to allow access for
      any task in the same thread group as the current ptrace parent.
      Signed-off-by: 's avatarJosh Stone <jistone@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: linux-security-module@vger.kernel.org
      Signed-off-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarJames Morris <james.l.morris@oracle.com>
      50523a29
  6. 25 May, 2016 1 commit
    • Jann Horn's avatar
      Yama: fix double-spinlock and user access in atomic context · dca6b414
      Jann Horn authored
      Commit 8a56038c ("Yama: consolidate error reporting") causes lockups
      when someone hits a Yama denial. Call chain:
      
      process_vm_readv -> process_vm_rw -> process_vm_rw_core -> mm_access
      -> ptrace_may_access
      task_lock(...) is taken
      __ptrace_may_access -> security_ptrace_access_check
      -> yama_ptrace_access_check -> report_access -> kstrdup_quotable_cmdline
      -> get_cmdline -> access_process_vm -> get_task_mm
      task_lock(...) is taken again
      
      task_lock(p) just calls spin_lock(&p->alloc_lock), so at this point,
      spin_lock() is called on a lock that is already held by the current
      process.
      
      Also: Since the alloc_lock is a spinlock, sleeping inside
      security_ptrace_access_check hooks is probably not allowed at all? So it's
      not even possible to print the cmdline from in there because that might
      involve paging in userspace memory.
      
      It would be tempting to rewrite ptrace_may_access() to drop the alloc_lock
      before calling the LSM, but even then, ptrace_may_access() itself might be
      called from various contexts in which you're not allowed to sleep; for
      example, as far as I understand, to be able to hold a reference to another
      task, usually an RCU read lock will be taken (see e.g. kcmp() and
      get_robust_list()), so that also prohibits sleeping. (And using e.g. FUSE,
      a user can cause pagefault handling to take arbitrary amounts of time -
      see https://bugs.chromium.org/p/project-zero/issues/detail?id=808.)
      
      Therefore, AFAIK, in order to print the name of a process below
      security_ptrace_access_check(), you'd have to either grab a reference to
      the mm_struct and defer the access violation reporting or just use the
      "comm" value that's stored in kernelspace and accessible without big
      complications. (Or you could try to use some kind of atomic remote VM
      access that fails if the memory isn't paged in, similar to
      copy_from_user_inatomic(), and if necessary fall back to comm, but
      that'd be kind of ugly because the comm/cmdline choice would look
      pretty random to the user.)
      
      Fix it by deferring reporting of the access violation until current
      exits kernelspace the next time.
      
      v2: Don't oops on PTRACE_TRACEME, call report_access under
      task_lock(current). Also fix nonsensical comment. And don't use
      GPF_ATOMIC for memory allocation with no locks held.
      This patch is tested both for ptrace attach and ptrace traceme.
      
      Fixes: 8a56038c ("Yama: consolidate error reporting")
      Signed-off-by: 's avatarJann Horn <jann@thejh.net>
      Acked-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarJames Morris <james.l.morris@oracle.com>
      dca6b414
  7. 04 May, 2016 1 commit
  8. 21 Apr, 2016 1 commit
  9. 21 Jan, 2016 1 commit
  10. 03 Aug, 2015 1 commit
  11. 28 Jul, 2015 1 commit
  12. 12 May, 2015 3 commits
  13. 28 Feb, 2015 2 commits
  14. 26 Mar, 2013 1 commit
  15. 20 Nov, 2012 3 commits
  16. 07 Sep, 2012 1 commit
  17. 05 Sep, 2012 1 commit
  18. 17 Aug, 2012 1 commit
  19. 10 Aug, 2012 1 commit
  20. 15 May, 2012 1 commit
  21. 23 Apr, 2012 1 commit
  22. 19 Apr, 2012 1 commit
  23. 15 Feb, 2012 1 commit
    • Kees Cook's avatar
      Yama: add PR_SET_PTRACER_ANY · bf06189e
      Kees Cook authored
      For a process to entirely disable Yama ptrace restrictions, it can use
      the special PR_SET_PTRACER_ANY pid to indicate that any otherwise allowed
      process may ptrace it. This is stronger than calling PR_SET_PTRACER with
      pid "1" because it includes processes in external pid namespaces. This is
      currently needed by the Chrome renderer, since its crash handler (Breakpad)
      runs external to the renderer's pid namespace.
      Signed-off-by: 's avatarKees Cook <keescook@chromium.org>
      Signed-off-by: 's avatarJames Morris <jmorris@namei.org>
      bf06189e
  24. 09 Feb, 2012 1 commit