From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751491AbcFWSEC (ORCPT ); Thu, 23 Jun 2016 14:04:02 -0400 Received: from emsm-gh1-uea11.nsa.gov ([8.44.101.9]:57242 "EHLO emsm-gh1-uea11.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750953AbcFWSD7 (ORCPT ); Thu, 23 Jun 2016 14:03:59 -0400 X-IronPort-AV: E=Sophos;i="5.26,518,1459814400"; d="scan'208";a="17155458" IronPort-PHdr: =?us-ascii?q?9a23=3AVp8gFRYiK7b/bhRvVEGp8XP/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZpM+5bnLW6fgltlLVR4KTs6sC0LuO9fi+EjVYuN6oizMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3Dwdp?= =?us-ascii?q?POO9QteU1JXvkbjssMSLOk1hv3mUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO?= =?us-ascii?q?9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFm2dfv/SXn?= =?us-ascii?q?YUPPoyFEEzZerh0dSS3E5xHzU5O5kSbgrOtm22HaOMTwCKg9Vjm5ru0jHBr0i2?= =?us-ascii?q?ECPjgh+W7akeR/iatapFSqoBkph8b2aYeTfNp5ZKWVKdETQ2xpQsZcVSwHBI6g?= =?us-ascii?q?OdghFe0EaN1EopH9ql1Glh63AQ2hFau70TNTrmPn1q09leI6GEfJ2xJ2TIFGi2?= =?us-ascii?q?jdsNigbPRaauuy1qSdiGyZN/4=3D?= X-IPAS-Result: =?us-ascii?q?A2HVAgCo7GpX/wHyM5BeGQEBAQEBgyCBAaYrAQEBAwaWSoY?= =?us-ascii?q?XAoEwTAEBAQEBAQICYieCMoIaAQEBAQIBIw8BRgULCw0LAgISFAICVwYBDAgBA?= =?us-ascii?q?YgkCLRekDcBAQEBAQEBAwEBAQEBASGBAYRegj8Igk6ECIEADIItgj0dBYgLhx+?= =?us-ascii?q?JU4kAhS2BaYd0DIU6j3xUgggcgWggiW6BNQEBAQ?= Subject: Re: Documenting ptrace access mode checking To: "Michael Kerrisk (man-pages)" , Jann Horn References: Cc: James Morris , linux-man , lkml , Kees Cook , "Eric W. Biederman" , linux-security-module , Linux API From: Stephen Smalley Organization: National Security Agency Message-ID: Date: Thu, 23 Jun 2016 14:05:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/21/2016 05:41 AM, Michael Kerrisk (man-pages) wrote: > 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.) That was the intent when the distinction was introduced, but it doesn't appear to have been properly maintained, e.g. there is now a common helper lock_trace() that is used for /proc/pid/{stack,syscall,personality} but checks PTRACE_MODE_ATTACH, and PTRACE_MODE_ATTACH is also used in timerslack_ns_write/show(). Likely should review and make them consistent. There was also some debate about proper handling of /proc/pid/fd. Arguably that one might belong back in the _ATTACH camp. > > 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.] Some ptrace access mode checks, such as checks when reading /proc/pid/stat, merely cause the output to be filtered/sanitized rather than an error to be returned to the caller. In these cases, accessing the file is not a security violation and there is no reason to generate a security audit record. This modifier suppresses the generation of such an audit record for the particular access check. > > 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. > > 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). > > Thanks, > > Michael >