Review of ptrace Yama ptrace_scope description

Review of ptrace Yama ptrace_scope description

[Michael Kerrisk (man-pages)]

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.

        2 ("admin-only attach")
               Only processes with the  CAP_SYS_PTRACE  capability  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.

Cheers,

Michael


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

Re: Review of ptrace Yama ptrace_scope description

[Jann Horn]

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

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


>        2 ("admin-only attach")
>               Only processes with the  CAP_SYS_PTRACE  capability  may
>               perform  PTRACE_MODE_ATTACH operations or trace children
>               that employ PTRACE_TRACEME.

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

Re: Review of ptrace Yama ptrace_scope description

[Michael Kerrisk (man-pages)]

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

Cheers,

Michael


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

Re: Review of ptrace Yama ptrace_scope description

[Jann Horn]

[-- 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 --]

Re: Review of ptrace Yama ptrace_scope description

[Michael Kerrisk (man-pages)]

Hi Jann,
...

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

Yep, thanks for catching that. Fixed now.

Cheers,

Michael


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

Re: Review of ptrace Yama ptrace_scope description

[Kees Cook]

On Mon, Jun 27, 2016 at 11:11 PM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> 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..."

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

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@gmail.com> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html