From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2F684158089 for ; Sun, 17 Sep 2023 20:49:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B2E812BC0BF; Sun, 17 Sep 2023 20:49:39 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7ECB42BC017 for ; Sun, 17 Sep 2023 20:49:39 +0000 (UTC) Received: by stitch (Postfix, from userid 1000) id 86540CB3C6; Sun, 17 Sep 2023 16:49:36 -0400 (EDT) Date: Sun, 17 Sep 2023 16:49:36 -0400 From: Michael Orlitzky To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] last rites (kinda, long masked): sys-apps/opentmpfiles Message-ID: References: <8459848.MhkbZ0Pkbq@pinacolada> <86bke1caqc.fsf@gentoo.org> <20230917060514.4314cb2b@Akita> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Archives-Salt: 64c3ea07-cb89-47bc-b0de-b537895667ec X-Archives-Hash: b364e352c854b20843fbdd378ee3cbec On 2023-09-17 20:28:49, Alexe Stefan wrote: > > There are 2 open pr's on the opentmpfiles github. One removes the > security vulnerability, but is non-compliant with the spec, the other > is (at least is a start of) a rewrite in c. The PR is still vulnerable. These checks, _chown() { local path=$2 uid=$1 if ! owned_by_root "${path}" ; then ... are insufficient to fix the vulnerability, because it's the parent path(s) that are the problem. If any parent path is writable by a non-root user, that non-root user can swap it out from under you, even if the thing you're operating on is root:root. AFAIK it's impossible to fix that in shell. In C, you can do a little openat() dance ensuring that each component of your path is safe from the root upwards -- that's why one of the suggestions is to rewrite opentmpfiles in C. > >As a result, opentmpfiles never should have tried to implement it, but > >its authors didn't know about those problems either. And while > >implementing tmpfiles in C has certain unavoidable race conditions, > >hooooooooo boy is the shell version swiss cheese. There's no safe way > >to run chown and chmod (the shell commands) as root in a directory you > >don't control, and that's a big part of what opentmpfiles does. The > >exploits for the shell version are kindergaren stuff. > > Is it really so easy to exploit it? > How would you do that? > The daemon runs "ln" or "ln -s", basically at its leisure, and waits for opentmpfiles to run again.