Re: Review of ptrace Yama ptrace_scope description

[Jann Horn <jann@thejh.net>]

[-- Attachment #1: Type: text/plain, Size: 6525 bytes --]

On Tue, Jun 28, 2016 at 08:11:36AM +0200, Michael Kerrisk (man-pages) wrote:
> Hi Jann,
> 
> On 06/25/2016 04:30 PM, Jann Horn wrote:
> >On Sat, Jun 25, 2016 at 09:30:43AM +0200, Michael Kerrisk (man-pages) wrote:
> >>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.
> >>
> >>       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.

Nit: The grammar in this sentence seems wrong to me.
s/or it have/or it must have/?

> 		By default, the predefined rela‐
>               tionship 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/security/Yama.txt  for
>               further details.
> 
>               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.
> 
> 
> Okay?

Sounds good to me. Kees?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]