From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751741AbcFUUH4 (ORCPT ); Tue, 21 Jun 2016 16:07:56 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:39515 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbcFUUHy convert rfc822-to-8bit (ORCPT ); Tue, 21 Jun 2016 16:07:54 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Michael Kerrisk \(man-pages\)" Cc: Jann Horn , James Morris , linux-man , Stephen Smalley , lkml , Kees Cook , linux-security-module , Linux API , Oleg Nesterov References: Date: Tue, 21 Jun 2016 14:55:36 -0500 In-Reply-To: (Michael Kerrisk's message of "Tue, 21 Jun 2016 11:41:16 +0200") Message-ID: <87ziqewc3r.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1bFRxd-0002lB-Km;;;mid=<87ziqewc3r.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+Qr0iO05mN4MzOhZjUhqZYtoxcYokgUVs= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.1 XMSolicitRefs_0 Weightloss drug * 0.2 T_XMDrugObfuBody_14 obfuscated drug references X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Michael Kerrisk \(man-pages\)" X-Spam-Relay-Country: X-Spam-Timing: total 646 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.6 (0.6%), b_tie_ro: 2.7 (0.4%), parse: 3.7 (0.6%), extract_message_metadata: 11 (1.6%), get_uri_detail_list: 7 (1.1%), tests_pri_-1000: 7 (1.1%), tests_pri_-950: 1.49 (0.2%), tests_pri_-900: 1.25 (0.2%), tests_pri_-400: 51 (7.8%), check_bayes: 49 (7.6%), b_tokenize: 21 (3.2%), b_tok_get_all: 14 (2.2%), b_comp_prob: 6 (1.0%), b_tok_touch_all: 3.7 (0.6%), b_finish: 0.85 (0.1%), tests_pri_0: 545 (84.3%), check_dkim_signature: 0.73 (0.1%), check_dkim_adsp: 4.1 (0.6%), tests_pri_500: 4.7 (0.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: Documenting ptrace access mode checking X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adding Oleg just because he seems to do most of the ptrace related maintenance these days. "Michael Kerrisk (man-pages)" writes: > Hi Jann, Stephen, et al. > > Jann, since you recently committed a patch in this area, and Stephen, > since you committed 006ebb40d3d much further back in time, I wonder if > you might help me by reviewing the text below that I propose to add to > the ptrace(2) man page, in order to document "ptrace access mode > checking" that is performed in various parts of the kernel-user-space > interface. Of course, I welcome input from anyone else as well. > > Here's the new ptrace(2) text. Any comments, technical or terminological > fixes, other improvements, etc. are welcome. > > [[ > Ptrace access mode checking > Various parts of the kernel-user-space API (not just ptrace(2) > operations), require so-called "ptrace access mode permissions" > which are gated by Linux Security Modules (LSMs) such as > SELinux, Yama, Smack, or the default LSM. Prior to Linux > 2.6.27, all such checks were of a single type. Since Linux > 2.6.27, two access mode levels are distinguished: > > PTRACE_MODE_READ > For "read" operations or other operations that are less > dangerous, such as: get_robust_list(2); kcmp(2); reading > /proc/[pid]/auxv, /proc/[pid]/environ, or > /proc/[pid]/stat; or readlink(2) of a /proc/[pid]/ns/* > file. > > PTRACE_MODE_ATTACH > For "write" operations, or other operations that are > more dangerous, such as: ptrace attaching > (PTRACE_ATTACH) to another process or calling > process_vm_writev(2). (PTRACE_MODE_ATTACH was effec‐ > tively the default before Linux 2.6.27.) > > Since Linux 4.5, the above access mode checks may be combined > (ORed) with one of the following modifiers: > > PTRACE_MODE_FSCREDS > Use the caller's filesystem UID and GID (see creden‐ > tials(7)) or effective capabilities for LSM checks. > > PTRACE_MODE_REALCREDS > Use the caller's real UID and GID or permitted capabili‐ > ties for LSM checks. This was effectively the default > before Linux 4.5. > > Because combining one of the credential modifiers with one of > the aforementioned access modes is typical, some macros are > defined in the kernel sources for the combinations: > > PTRACE_MODE_READ_FSCREDS > Defined as PTRACE_MODE_READ | PTRACE_MODE_FSCREDS. > > PTRACE_MODE_READ_REALCREDS > Defined as PTRACE_MODE_READ | PTRACE_MODE_REALCREDS. > > PTRACE_MODE_ATTACH_FSCREDS > Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS. > > PTRACE_MODE_ATTACH_REALCREDS > Defined as PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS. > > One further modifier can be ORed with the access mode: > > PTRACE_MODE_NOAUDIT (since Linux 3.3) > Don't audit this access mode check. > > [I'd quite welcome some text to explain "auditing" here.] AKA don't let the audit subsystem know. Which tends to generate audit records capable is called. > > The algorithm employed for ptrace access mode checking deter‐ > mines whether the calling process is allowed to perform the > corresponding action on the target process, as follows: > > 1. If the calling thread and the target thread are in the same > thread group, access is always allowed. This test only exsits because the LSMs historically and I suspect continue to be broken and deny a process the ability to ptrace itself. > > 2. If the access mode specifies PTRACE_MODE_FSCREDS, then for > the check in the next step, employ the caller's filesystem > user ID and group ID (see credentials(7)); otherwise (the > access mode specifies PTRACE_MODE_REALCREDS, so) use the > caller's real user ID and group ID. > > 3. Deny access if neither of the following is true: > > · The real, effective, and saved-set user IDs of the target > match the caller's user ID, and the real, effective, and > saved-set group IDs of the target match the caller's > group ID. > > · The caller has the CAP_SYS_PTRACE capability. > > 4. Deny access if the target process "dumpable" attribute has > a value other than 1 (SUID_DUMP_USER; see the discussion of > PR_SET_DUMPABLE in prctl(2)), and the caller does not have > the CAP_SYS_PTRACE capability in the user namespace of the > target process. > > 5. The kernel LSM security_ptrace_access_check() interface is > invoked to see if ptrace access is permitted. The results > depend on the LSM. The implementation of this interface in > the default LSM performs the following steps: > > a) If the access mode includes PTRACE_MODE_FSCREDS, then > use the caller's effective capability set in the follow‐ > ing check; otherwise (the access mode specifies > PTRACE_MODE_REALCREDS, so) use the caller's permitted > capability set. > > b) Deny access if neither of the following is true: > > · The caller's capabilities are a proper superset of the > target process's permitted capabilities. > > · The caller has the CAP_SYS_PTRACE capability in the > target process's user namespace. > > Note that the default LSM does not distinguish between > PTRACE_MODE_READ and PTRACE_MODE_ATTACH. > > 6. If access has not been denied by any of the preceding > steps, then access is allowed. > ]] > > There are accompanying changes to various pages that refer to > the new text in ptrace(2), so that, for example, kcmp(2) adds: > > Permission to employ kcmp() is governed by ptrace access mode > PTRACE_MODE_ATTACH_REALCREDS checks against both pid1 and pid2; > see ptrace(2). > > and proc.5 has additions such as: > > /proc/[pid]/auxv (since 2.6.0-test7) > ... > Permission to access this file is governed by a ptrace > access mode PTRACE_MODE_READ_FSCREDS check; see > ptrace(2). > > /proc/[pid]/cwd > ... > Permission to dereference or read (readlink(2)) this > symbolic link is governed by a ptrace access mode > PTRACE_MODE_READ_FSCREDS check; see ptrace(2). Hmm. When I gave this level of detail about the user namespace permission checks you gave me some flack, because it was not particularly comprehensible to the end users. I think you deserve the same feedback. How do we say this in a way that does not describes a useful way to think about it. I read this and I know a lot of what is going on and my mind goes numb. How about something like this: If the callers uid and gid are the same as a processes uids and gids and the processes is configured to allow core dumps (aka it was never setuid or setgid) then the caller is allowed to ptrace a process. Otherwise the caller must have CAP_SYS_PTRACE. Linux security modules impose additional restrictions. For consistency access to various process attributes are guarded with the same security checks as the ptrace system call itself. As they are all methods to get information about a process. We certainly need something that gives a high level view so people reading the man page can know what to expect. If you get down into the weeds we run the danger of people beginning to think they can depend upon bugs in the implementation. Eric