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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 16 Dec 2020 03:33:43 +0100 From: Jann Horn <jannh@...gle.com> To: Ted Estes <ted@...twarecrafters.com> Cc: "Alejandro Colomar (man-pages)" <alx.manpages@...il.com>, Jann Horn <jann@...jh.net>, Pavel Emelyanov <xemul@...nvz.org>, Oleg Nesterov <oleg@...sign.ru>, Andrew Morton <akpm@...ux-foundation.org>, Michael Kerrisk <mtk.manpages@...il.com>, Kees Cook <keescook@...omium.org>, linux-man <linux-man@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: [Bug 210655] ptrace.2: documentation is incorrect about access checking threads in same thread group On Wed, Dec 16, 2020 at 3:21 AM Ted Estes <ted@...twarecrafters.com> 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@...il.com> 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.
Powered by blists - more mailing lists