Re: Review of ptrace Yama ptrace_scope description

[Michael Kerrisk (man-pages)]

Hi Kees,

On 06/28/2016 10:55 PM, Kees Cook wrote:
> On Mon, Jun 27, 2016 at 11:11 PM, Michael Kerrisk (man-pages)
> <mtk.manpages@xxxxxxxxx> 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.
>
> Maybe clarify "additional credentials that may exist in memory only and thus..."

Done.

> > > >        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).

Thanks, Fixed.

> >               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.

Ahhh -- thanks. I'd not understood that to be the case. Fixed now.

> >               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"?

So, I've reworked that last piece somewhat to something
I hope is a little clearer:

       With respect to values 1 and 2, note  that  creating  a  new  user
       namespace  effectively  removes  the  protection  offered by Yama.
       This is because a process  in  the  parent  user  namespace  whose
       effective  UID matches the UID of the creator of a child namespace
       has all capabilities (including  CAP_SYS_PTRACE)  when  performing
       operations  within  the  child user namespace (and further-removed
       descendants of that  namespace).   Consequently,  when  a  process
       tries  to  use user namespaces to sandbox itself, it inadvertently
       weakens the protections offered by the Yama LSM.

> Otherwise it looks great, thanks for writing it up!

No problem. Thanks for reviewing!

Cheers,

Michael


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