* Review of ptrace Yama ptrace_scope description
@ 2016-06-25 7:30 Michael Kerrisk (man-pages)
2016-06-25 14:30 ` Jann Horn
0 siblings, 1 reply; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-06-25 7:30 UTC (permalink / raw)
To: Kees Cook
Cc: mtk.manpages, Linux API, linux-man, linux-security-module, lkml,
Casey Schaufler, James Morris
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Review of ptrace Yama ptrace_scope description
2016-06-25 7:30 Review of ptrace Yama ptrace_scope description Michael Kerrisk (man-pages)
@ 2016-06-25 14:30 ` Jann Horn
2016-06-28 6:11 ` Michael Kerrisk (man-pages)
0 siblings, 1 reply; 7+ messages in thread
From: Jann Horn @ 2016-06-25 14:30 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Kees Cook, Linux API, linux-man, linux-security-module, lkml,
Casey Schaufler, James Morris
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Review of ptrace Yama ptrace_scope description
2016-06-25 14:30 ` Jann Horn
@ 2016-06-28 6:11 ` Michael Kerrisk (man-pages)
2016-06-28 20:50 ` Jann Horn
2016-06-28 20:55 ` Kees Cook
0 siblings, 2 replies; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-06-28 6:11 UTC (permalink / raw)
To: Jann Horn
Cc: mtk.manpages, Kees Cook, Linux API, linux-man,
linux-security-module, lkml, Casey Schaufler, James Morris
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Review of ptrace Yama ptrace_scope description
2016-06-28 6:11 ` Michael Kerrisk (man-pages)
@ 2016-06-28 20:50 ` Jann Horn
2016-06-29 4:49 ` Michael Kerrisk (man-pages)
2016-06-28 20:55 ` Kees Cook
1 sibling, 1 reply; 7+ messages in thread
From: Jann Horn @ 2016-06-28 20:50 UTC (permalink / raw)
To: Michael Kerrisk (man-pages), Kees Cook
Cc: Linux API, linux-man, linux-security-module, lkml,
Casey Schaufler, James Morris
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Review of ptrace Yama ptrace_scope description
2016-06-28 6:11 ` Michael Kerrisk (man-pages)
2016-06-28 20:50 ` Jann Horn
@ 2016-06-28 20:55 ` Kees Cook
2016-06-29 5:05 ` Michael Kerrisk (man-pages)
1 sibling, 1 reply; 7+ messages in thread
From: Kees Cook @ 2016-06-28 20:55 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: Jann Horn, Linux API, linux-man, linux-security-module, lkml,
Casey Schaufler, James Morris
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Review of ptrace Yama ptrace_scope description
2016-06-28 20:50 ` Jann Horn
@ 2016-06-29 4:49 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-06-29 4:49 UTC (permalink / raw)
To: Jann Horn, Kees Cook
Cc: mtk.manpages, Linux API, linux-man, linux-security-module, lkml,
Casey Schaufler, James Morris
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Review of ptrace Yama ptrace_scope description
2016-06-28 20:55 ` Kees Cook
@ 2016-06-29 5:05 ` Michael Kerrisk (man-pages)
0 siblings, 0 replies; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2016-06-29 5:05 UTC (permalink / raw)
To: Kees Cook
Cc: mtk.manpages, Jann Horn, Linux API, linux-man,
linux-security-module, lkml, Casey Schaufler, James Morris
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/
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-06-29 5:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-25 7:30 Review of ptrace Yama ptrace_scope description Michael Kerrisk (man-pages)
2016-06-25 14:30 ` Jann Horn
2016-06-28 6:11 ` Michael Kerrisk (man-pages)
2016-06-28 20:50 ` Jann Horn
2016-06-29 4:49 ` Michael Kerrisk (man-pages)
2016-06-28 20:55 ` Kees Cook
2016-06-29 5:05 ` Michael Kerrisk (man-pages)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).