linux-kernel - Re: [Bug 210655] ptrace.2: documentation is incorrect about access checking threads in same thread group

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.