Messages in this thread | | | Subject | Re: Review of ptrace Yama ptrace_scope description | From | "Michael Kerrisk (man-pages)" <> | Date | Wed, 29 Jun 2016 07:05:08 +0200 |
| |
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/
| |