On Wed, Dec 16, 2020 at 3:21 AM Ted Estes <ted@xxxxxxxxxxxxxxxxxxxx> wrote: > On 12/15/2020 6:01 PM, Jann Horn wrote: > > On Wed, Dec 16, 2020 at 12:25 AM Alejandro Colomar (man-pages) > > <alx.manpages@xxxxxxxxx> wrote: > >> On 12/16/20 12:23 AM, Alejandro Colomar (man-pages) wrote: > >>> On 12/16/20 12:07 AM, Jann Horn wrote: > >>>> As the comment explains, you can't actually *attach* > >>>> to another task in the same thread group; but that's > >>>> not because of the ptrace-style access check rules, > >>>> but because specifically *attaching* to another task > >>>> in the same thread group doesn't work. > > As I said, attaching indeed doesn't work. But that's not what "Ptrace > > access mode checking" means. As the first sentence of that section > > says: > > > > | Various parts of the kernel-user-space API (not just ptrace() > > | operations), require so-called "ptrace access mode" checks, > > | whose outcome determines whether an operation is > > | permitted (or, in a few cases, causes a "read" operation > > | to return sanitized data). > > > > You can find these places by grepping for \bptrace_may_access\b - > > operations like e.g. the get_robust_list() syscall will always succeed > > when inspecting other tasks in the caller's thread group thanks to > > this rule. > > Ah, yes. I missed that back reference while trying to digest that > rather meaty man page. A grep on the man page source tree does show a > number of references to "ptrace access mode". > > That said, the ptrace(2) man page also directly references the ptrace > access mode check under both PTRACE_ATTACH and PTACE_SEIZE: > > | Permission to perform a PTRACE_ATTACH is governed by a ptrace | access > mode PTRACE_MODE_ATTACH_REALCREDS check; see below. As confirmed, the > "same thread group" rule does not apply to either of those operations. A > re-wording of rule 1 similar to this might help avoid confusion: 1. If > the calling thread and the target thread are in the same thread group: > a. For ptrace() called with PTRACE_ATTACH or PTRACE_SEIZE, access is > NEVER allowed. b. For all other so-called "ptrace access mode checks", > access is ALWAYS allowed. --Ted Yeah, maybe. OTOH I'm not sure whether it really makes sense to explain this as being part of a security check, or whether it should be explained separately as a restriction on PTRACE_ATTACH and PTRACE_SEIZE (with a note like "(irrelevant for ptrace attachment)" on rule 1). But I don't feel strongly about it either way.
