| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 22 Jun 2016 21:21:29 +0200
From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To: Jann Horn <jann@...jh.net>
Cc: mtk.manpages@...il.com, James Morris <jmorris@...ei.org>,
linux-man <linux-man@...r.kernel.org>,
Stephen Smalley <sds@...ho.nsa.gov>,
lkml <linux-kernel@...r.kernel.org>,
Kees Cook <keescook@...omium.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
linux-security-module <linux-security-module@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: Documenting ptrace access mode checking
Hi Jann,
On 06/21/2016 10:55 PM, Jann Horn wrote:
> On Tue, Jun 21, 2016 at 11:41:16AM +0200, 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.
>
> As others have said, I'm surprised about seeing documentation about
> kernel-internal constants in manpages - but I think it might be a good
> thing to have there, given that people who look at ptrace(2) are likely
> to be interested in low-level details.
I agree that it is a little surprising to add kernel-internal
constants in a man page. (There are precedents, but they are few.)
But see my reply to Kees. It's more than just explaining low level
details: there are various kinds of user-space behavior differences
(real vs filesystem credentials; permitted vs effective capabilities)
produced by the ptrace_may_access() checks, and those behaviors need
to be described and *somehow* labeled for cross-referencing from
other man pages.
>> [[
>> 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
>
> s/may/must/; otherwise __ptrace_may_access() will yell about the kernel
> code being broken and deny access.
Good point. I changed "may" to "are". ("must" is not quite right to my
"user-space" ear; it might be misread as implying that the user-space
developer must do something.)
>> (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.]
>>
>> 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.
>
> Might want to add a "for historical reasons" or so here.
Can you be a little more precise about "here", and maybe tell me why
you think it helps?
>> 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.
>
> Might want to also specify here (like below) that the caller needs to
> have the capability relative to the user ns of the target.
Done.
>> 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:
>
> For people who are unaware of how the LSM API works, it might be good to
> clarify that the commoncap LSM is *always* invoked; otherwise, it might
> give the impression that using another LSM would replace it.
As we can see, I am one of those who are unaware of how the LSM API
works :-/.
> (Also, are there other documents that refer to it as "default LSM"? I
> think that that term is slightly confusing.)
No, that's a terminological confusion of my own making. Fixed now.
I changed this text to:
Various parts of the kernel-user-space API (not just ptrace(2)
operations), require so-called "ptrace access mode permissions"
which are gated by any enabled Linux Security Module (LSMs)—for
example, SELinux, Yama, or Smack—and by the the commoncap LSM
(which is always invoked). 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:
BTW, can you point me at the piece(s) of kernel code that show that
"commoncap" is always invoked in addition to any other LSM that has
been installed?
>> 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.
>
> This also requires the caller and the target to be in the same user
> namespace.
Thanks! Fixed.
>> · 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).
>
> (Actually, kcmp() just needs READ access - you described that accurately
> earlier, but it's wrong here.)
D'oh! Thanks!
>> 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).
>
> That sounds great! :)
Thanks for the review!
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Powered by blists - more mailing lists