Re: Review of ptrace Yama ptrace_scope description

On Mon, Jun 27, 2016 at 11:11 PM, Michael Kerrisk (man-pages)
[off-list ref] wrote:

Hi Jann,


On 06/25/2016 04:30 PM, Jann Horn wrote:

quoted

On Sat, Jun 25, 2016 at 09:30:43AM +0200, Michael Kerrisk (man-pages)
wrote:

quoted

Hi Kees,

So, last year, I added some documentation to ptrace(2) to describe
the Yama ptrace_scope file. I don't think I asked you for review
at the time, but in the light of other changes to the ptrace(2)
page, it occurred to me that it might be a good idea to ask you
to check the text below to see if anything is missing or could be
improved. Might you have a moment for that?

   /proc/sys/kernel/yama/ptrace_scope
       On systems with the Yama Linux Security Module (LSM)  installed
       (i.e.,  the  kernel  was configured with CONFIG_SECURITY_YAMA),
       the /proc/sys/kernel/yama/ptrace_scope  file  (available  since
       Linux  3.4)  can  be  used  to  restrict the ability to trace a
       process with ptrace(2) (and thus also the ability to use  tools
       such  as  strace(1) and gdb(1)).  The goal of such restrictions
       is to prevent attack escalation whereby a  compromised  process
       can  ptrace-attach  to  other  sensitive processes (e.g., a GPG
       agent or an SSH session) owned by the user  in  order  to  gain
       additional credentials and thus expand the scope of the attack.

Maybe clarify "additional credentials that may exist in memory only and thus..."

quoted

quoted

       More precisely, the Yama LSM limits two types of operations:

       *  Any   operation   that   performs   a   ptrace  access  mode
          PTRACE_MODE_ATTACH     check—for      example,      ptrace()
          PTRACE_ATTACH.   (See the "Ptrace access mode checking" dis‐
          cussion above.)

       *  ptrace() PTRACE_TRACEME.

       A process that has the CAP_SYS_PTRACE capability can update the
       /proc/sys/kernel/yama/ptrace_scope file with one of the follow‐
       ing values:

       0 ("classic ptrace permissions")
              No additional restrictions on  operations  that  perform
              PTRACE_MODE_ATTACH  checks  (beyond those imposed by the
              commoncap and other LSMs).

              The use of PTRACE_TRACEME is unchanged.

       1 ("restricted ptrace") [default value]
              When   performing   an   operation   that   requires   a
              PTRACE_MODE_ATTACH  check, the calling process must have
              a predefined relationship with the target  process.   By
              default,  the predefined relationship is that the target
              process must be a child of the caller.

              A target process can employ the prctl(2)  PR_SET_PTRACER
              operation  to declare a different PID that is allowed to
              perform PTRACE_MODE_ATTACH  operations  on  the  target.
              See   the   kernel   source   file   Documentation/secu‐
              rity/Yama.txt for further details.

              The use of PTRACE_TRACEME is unchanged.

(namespaced) CAP_SYS_PTRACE is also sufficient here.


Both here and in the "admin-only attach" case, it is IMO important to
note that creating a user namespace effectively removes the Yama
protection because the owner of a namespace, when accessing its
contents from outside, is relatively capable.

This means that when a process tries to use namespaces to sandbox
itself, it inadvertently makes itself more accessible.

(This could probably be worked around in the kernel, but such a
workaround would likely not be default, but rather opt-in via a new
flag for clone() and unshare() or so.)

Tanks for catching this!

So I've made that section of text:

       A  process  that  has the CAP_SYS_PTRACE capability can update the
       /proc/sys/kernel/yama/ptrace_scope file with one of the  following
       values:

       0 ("classic ptrace permissions")
              No  additional  restrictions  on  operations  that  perform
              PTRACE_MODE_ATTACH checks (beyond those imposed by the com‐
              moncap and other LSMs).

              The use of PTRACE_TRACEME is unchanged.

       1 ("restricted ptrace") [default value]
              When    performing    an    operation   that   requires   a
              PTRACE_MODE_ATTACH check, the calling process  must  either
              have the CAP_SYS_PTRACE capability in the user namespace of
              the target process or it  have  a  predefined  relationship
              with  the target process.  By default, the predefined rela‐
              tionship is that the target process must be a child of  the
              caller.

More accurately, must be a descendant of the caller (grand child is fine, etc).

              A  target  process  can  employ the prctl(2) PR_SET_PTRACER
              operation to declare a different PID  that  is  allowed  to
              perform  PTRACE_MODE_ATTACH  operations on the target.  See
              the kernel source file Documentation/security/Yama.txt  for
              further details.

I would say "additional" pid to perform... since its ancestors can
still ptrace it too.

              The use of PTRACE_TRACEME is unchanged.

       2 ("admin-only attach")
              Only  processes  with  the CAP_SYS_PTRACE capability in the
              user  namespace  of  the   target   process   may   perform
              PTRACE_MODE_ATTACH operations or trace children that employ
              PTRACE_TRACEME.

       3 ("no attach")
              No process may  perform  PTRACE_MODE_ATTACH  operations  or
              trace children that employ PTRACE_TRACEME.

              Once  this value has been written to the file, it cannot be
              changed.

       With respect to values 1 and 2, note that creating a  user  names‐
       pace effectively removes the Yama protection, because the owner of
       a  namespace,  when  accessing  its  members  from  outside,   has
       CAP_SYS_PTRACE  within  the  namespace.   This  means  that when a
       process tries to use namespaces to  sandbox  itself,  it  inadver‐
       tently weakens the protections offered by the Yama LSM.

Perhaps clarify "has CAP_SYS_PTRACE within all its namespaces, so the
ancestry rule is bypassed"?

Okay?

Otherwise it looks great, thanks for writing it up!

-Kees

Cheers,

Michael


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

-- 
Kees Cook
Chrome OS & Brillo Security