From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gardel.0pointer.net (gardel.0pointer.net [85.214.157.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0A9CE25D521; Wed, 7 May 2025 14:22:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=85.214.157.71 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746627746; cv=none; b=HI/TNeZIIqz2pBAJtnw91aO1UnqMZicEj+xqTUgE/F+HFmrAZL14Og1BAtmtV7YRSIAX3lxcK1UAM/DjwzDPO6FVIYC9ss1s8L7yZllnQuj+iP4KTgqlpkUz1PBptoZZNgIf7qqFrhNIvGU2EPoODB2QQqb4a+zdlJ1Zl8IcTEA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746627746; c=relaxed/simple; bh=XL8XfkDiqMxumAe7zHX0ZUVrrfqkX7k7oFAaizD+w/o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IChi6lxpbUcaYmg0xc0RHX15wjdH+XsMWqFyZrfu0fLqz7YoZ3/6e71Hef5Z67NJe7OXC8JaugBRHNW9kMqxCWg96lqpsyQ/b6cFzZ6++fWPZBblO0hWMyKd1IRZ9Zl97Fkx2UFkES7OqsXYwU523WuRa4+elxO/omH2ivqEUxc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=0pointer.de; spf=pass smtp.mailfrom=0pointer.de; arc=none smtp.client-ip=85.214.157.71 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=0pointer.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=0pointer.de Received: from gardel-login.0pointer.net (gardel-mail [85.214.157.71]) by gardel.0pointer.net (Postfix) with ESMTP id 1D7E4E802CC; Wed, 7 May 2025 16:22:15 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id 9820E16005E; Wed, 7 May 2025 16:22:14 +0200 (CEST) Date: Wed, 7 May 2025 16:22:14 +0200 From: Lennart Poettering To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: Kuniyuki Iwashima , brauner@kernel.org, alexander@mihalicyn.com, bluca@debian.org, daan.j.demeyer@gmail.com, davem@davemloft.net, david@readahead.eu, edumazet@google.com, horms@kernel.org, jack@suse.cz, jannh@google.com, kuba@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, me@yhndnzj.com, netdev@vger.kernel.org, oleg@redhat.com, pabeni@redhat.com, viro@zeniv.linux.org.uk, zbyszek@in.waw.pl, linux-security-module@vger.kernel.org Subject: Re: [PATCH RFC v3 08/10] net, pidfs, coredump: only allow coredumping tasks to connect to coredump socket Message-ID: References: <20250506-zugabe-bezog-f688fbec72d3@brauner> <20250506191817.14620-1-kuniyu@amazon.com> <20250507.ohsaiQuoh3uo@digikod.net> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250507.ohsaiQuoh3uo@digikod.net> On Mi, 07.05.25 13:51, Mickaël Salaün (mic@digikod.net) wrote: > What if the task send a "fake" coredump and just after that really > coredump? There could be a race condition on the server side when > checking the coredump property of this pidfd. > > Could we add a trusted header to the coredump payload that is always > written by the kernel? This would enable to read a trusted flag > indicating if the following payload is a coredumped generated by the > kernel or not. With my systemd hat on I must say I don't really care if the coredump is "authentic" or not. The coredump is untrusted data anyway, it needs to be quarantined from systemd-coredump's PoV, there's no security value in distinguishing if some random user's process was sent to the handler because the user called raise(SIGSEGV) or because the user called connect() to our socket. The process is under user control in almost all ways anyways, they can rearrange its internals in almost any way already, play any games they want. It's of very little value if the receiving side can determine if the serialization of potential complete garbage was written out by the kernel or by the process' own code. Moreover, in systemd-coredump we these days collect not only classic ELF coredumps passed to us by the kernel, but also other forms of crashes. For example if a Python program dies because of an uncaught exception this is also passed to systemd-coredump, and treated the same way in regards to metadata collection, logging, storage, recycling and so on. Conceptually a python crash like that and a process level crash are the same thing for us, we treat them the same. And of course, Python crashes like this are *inherently* a userspace concept, hence we explicitly want to accept them. Hence even if we'd be able to distinguish "true" from "fake" coredumps we'd still not care or change our behaviour much, because we are *as* *much* interested in user-level crashes as in kernel handled crashes. Lennart -- Lennart Poettering, Berlin