Message-ID: <CAGXu5jJJFL1YtwEvqhTz2RrVSbszUF32QhN6BH92aWqqpPyNew@mail.gmail.com>
Date:	Tue, 28 Jun 2016 13:55:53 -0700
From:	Kees Cook <keescook@...omium.org>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	Jann Horn <jann@...jh.net>, Linux API <linux-api@...r.kernel.org>,
	linux-man <linux-man@...r.kernel.org>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	James Morris <jmorris@...ei.org>
Subject: Re: Review of ptrace Yama ptrace_scope description

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

Powered by blists - more mailing lists