From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6298FC4361B for ; Wed, 16 Dec 2020 02:35:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2DD5622CB8 for ; Wed, 16 Dec 2020 02:35:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726114AbgLPCew (ORCPT ); Tue, 15 Dec 2020 21:34:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbgLPCew (ORCPT ); Tue, 15 Dec 2020 21:34:52 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 10908C0613D6 for ; Tue, 15 Dec 2020 18:34:12 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id u18so44575927lfd.9 for ; Tue, 15 Dec 2020 18:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MOHF+gl+OMMG1QgmH1V73+fyHVx0MkwzoVxV0JG8Lv4=; b=UPu4AGLueLqzTSIYqU9zfFBm4GlxC9GiHWclpWDDa/Q4HmYhRH3lve+WEsjYRN32OP JI7O5g8d1gUOxKuDoPdl8KtDvxlQNWLMPpSAYfcCnmC5qRhxmMWajRMZOvQay/7VFytW gcocwfkI8vk9Z1Ete5LvKqVuY4zIVR5OKZs03EIMnxC7jk3/rEiIx7dcKuh5sL8ta2+9 BKb9WyPmXwtnKgsClhmqlsfQPT86nVSdBD3sFCa5dA0woCiaULnMe3QIneKWmgdeOUTE Xp1Z7eoWbeiImr3sXalcs2GYF1Yp1fAoyvp4OvSS+MwuOfu86ZiZ3hBqzUpGwhQVM41j YBdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MOHF+gl+OMMG1QgmH1V73+fyHVx0MkwzoVxV0JG8Lv4=; b=N3WBi+05sZulmzoX+IW2XsX2zrV+UQhReQnXha/jbIMSmtUzqDCaW8R29wCh1rcxiA Xw7mhxbxE7Z+ylvSDpSY6RNNIRalhoPiQ9f8bBFx9fzCvfPoL44btfor4lzdHyyOw6YB Wh+eSAE1c+5jdUOp36nDmFk0RCyCVUChsCrRCXm6LbLZrP3eVEbtvSnqEdszN1/GPpvB PtJrpI1ZFbdHys1omz8mk2L/X3rQ4fgIFabi7MYX39Q8gskTCJjXHhUyL2jyJU6Gk8m2 NC96IDZTZNleLSZGh8L0l+/wtawYZ5ka+m4H8/PMVG/WRwYUwT2rBidNDk/yFFJ1FGAQ DmNw== X-Gm-Message-State: AOAM533mcspoUSGuzUsQQeITS9Mf8vKwrYhhP+29L+i7Izrltsrke9BU 64qJ1I7KeLAWpYgyO/TWpSy7LWwpTqvgwbl1GCpaWg== X-Google-Smtp-Source: ABdhPJwbunInmrnvmwAUoXogNkc3hzOmkqVwILIDiVk5ZmNQDWo0gIvrLQZ9NbTUm4ZvCdP6dVtg/cInyWGfmv1GnXU= X-Received: by 2002:a19:4c84:: with SMTP id z126mr11398098lfa.69.1608086050251; Tue, 15 Dec 2020 18:34:10 -0800 (PST) MIME-Version: 1.0 References: <0e5189c0-9e9b-ac34-825c-619a9a6ef682@gmail.com> <5062fe43-ca37-134f-89ad-57fbd8c312ba@softwarecrafters.com> In-Reply-To: <5062fe43-ca37-134f-89ad-57fbd8c312ba@softwarecrafters.com> From: Jann Horn Date: Wed, 16 Dec 2020 03:33:43 +0100 Message-ID: Subject: Re: [Bug 210655] ptrace.2: documentation is incorrect about access checking threads in same thread group To: Ted Estes Cc: "Alejandro Colomar (man-pages)" , Jann Horn , Pavel Emelyanov , Oleg Nesterov , Andrew Morton , Michael Kerrisk , Kees Cook , linux-man , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 16, 2020 at 3:21 AM Ted Estes wrote: > On 12/15/2020 6:01 PM, Jann Horn wrote: > > On Wed, Dec 16, 2020 at 12:25 AM Alejandro Colomar (man-pages) > > 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.