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