From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752452AbcF1GLo (ORCPT ); Tue, 28 Jun 2016 02:11:44 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:35441 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750836AbcF1GLl (ORCPT ); Tue, 28 Jun 2016 02:11:41 -0400 Subject: Re: Review of ptrace Yama ptrace_scope description To: Jann Horn References: <20160625143006.GA24730@pc.thejh.net> Cc: mtk.manpages@gmail.com, Kees Cook , Linux API , linux-man , linux-security-module , lkml , Casey Schaufler , James Morris From: "Michael Kerrisk (man-pages)" Message-ID: <0017835d-c672-02fe-dab8-d1b11c100c24@gmail.com> Date: Tue, 28 Jun 2016 08:11:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160625143006.GA24730@pc.thejh.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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/