| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 29 Jun 2016 07:05:08 +0200
From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: mtk.manpages@...il.com, 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
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@...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..."
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/
Powered by blists - more mailing lists