Adding Oleg just because he seems to do most of the ptrace related
maintenance these days.
"Michael Kerrisk (man-pages)" [off-list ref] 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‐
29 more quoted lines
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.
28 more quoted lines
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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html