From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by sourceware.org (Postfix) with ESMTPS id 2BBD0383EC57 for ; Mon, 27 Jun 2022 14:25:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2BBD0383EC57 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BF6CAB8106E; Mon, 27 Jun 2022 14:25:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 729D5C341C8; Mon, 27 Jun 2022 14:25:38 +0000 (UTC) Date: Mon, 27 Jun 2022 16:25:35 +0200 From: Christian Brauner To: Mark Wielaard Cc: Florian Weimer , libc-alpha@sourceware.org Subject: Re: [PATCH 3/4] tst-pidfd.c: Test is UNSUPPORTED without PTRACE_MODE_ATTACH_REALCREDS Message-ID: <20220627142535.3dkmeavirvnntnx3@wittgenstein> References: <20220626205915.33201-1-mark@klomp.org> <20220626205915.33201-4-mark@klomp.org> <87h747nmud.fsf@mid.deneb.enyo.de> <874k06cq9t.fsf@oldenburg.str.redhat.com> <20220627115141.s4zjaac7ixceq7rs@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2022 14:25:44 -0000 On Mon, Jun 27, 2022 at 04:17:17PM +0200, Mark Wielaard wrote: > Hi, > > On Mon, Jun 27, 2022 at 01:51:41PM +0200, Christian Brauner wrote: > > On Mon, Jun 27, 2022 at 01:14:06PM +0200, Florian Weimer via Libc-alpha wrote: > > > * Mark Wielaard: > > > > pidfd_getfd is mentioned (and allowed) by the seccomp filter, but the > > > > syscall also needs the process to have PTRACE_MODE_ATTACH_REALCREDS > > > > (which is really PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS). Which it > > > > doesn't have. If the process doesn't then pidfd_getfd is defined as > > > > failing and setting errno to EPERM. > > > > > > But what does it mean for a process to have PTRACE_MODE_REALCREDS? > > > > #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS) > > > > PTRACE_MODE_ATTACH_REALCREDS means > > * PTRACE_MODE_REALCREDS which means cred->{g,u}id of the task are used > > for permission checking: > > > > So it's a bit nasty here but roughly if the ptracer's real {g,u}id match > > the target task's (ptracee's) effective, save, and real [g,u]id then > > you'passed the first stage of permission checking. > > > > If ptracer's [g,u]id aren't matching the ptracee's effective, saved, and > > real [g,u]id the ptracer needs CAP_SYS_PTRACE in the ptracee's userns. > > That will also get you past the first state of permission checking. > > > > If both don't apply the request is denied with -EPERM. > > > > The second stage of permission checking is: > > (1) If the task isn't dumpable then you'll need CAP_SYS_PTRACE in the > > ptracee's mm user namespace. That userns may differ from the > > ptracee's current userns if the ptracee's userns wasn't privileged > > over the inode of the file it exec'ed and thus could be an ancestor > > userns (see would_dump()). > > (2) The LSMs might deny your request. > > Right, it is pretty difficult to determine why you got an EPERM. But > failing with EPERM is documented behaviour for pidfd_getfd, so IMHO if > we get EPERM we should simply skip the test whatever the "real" reason > is. > > The ptrace manual page lists the whole (6 step) algorithm under > "Ptrace access mode checking": > https://man7.org/linux/man-pages/man2/ptrace.2.html > > It also depends on (not) having CAP_SYS_PTRACE and the permission > might be dependend on /proc/sys/kernel/yama/ptrace_scope Yeah, to be frank, I consider ptrace_may_access() to be the worst piece of permission checking code in the kernel. It just takes and shakes so many core concepts that it's hard to understand and difficult to figure out what exactly caused it to fail.