From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 8D9D13858420 for ; Thu, 11 Apr 2024 10:14:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8D9D13858420 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8D9D13858420 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712830465; cv=none; b=C1bKGOrsalqyJjpxafCWkJNhUyu/R3LKHbguAqQ3K+EB/8ry5v2K1ie3kzFD2JUwDYOTR38xClR6PEQthmQpmfQp7vezeRXaJ3wyQOgMSYNVYIlap6M+OoTKoJd9+MABS5NnI4PaNvrLp9KaZKtKzeL0+9k5Pqg7GlAScFs5EwQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712830465; c=relaxed/simple; bh=xGIMhGFuClLyatvYcWOlQIbRsW/Xs18Y2fssSW4d5Bw=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=w6RPY6lktV/TgPTN5no3ByKWXAITHLzb9QLM9aUPq9BTG+FmFpdZIA9X0GgfeyuxQkt14C6X8WjR3SOFU2YzyaPY5qe0wBwYJmuGUXvslVcYqyMkWVSxnWLBp2knPv4YotzsWrs3+eVaKJhf4slSDlmxrg44qg0xp8Kekqm2DkQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id A74F93000595; Thu, 11 Apr 2024 12:14:22 +0200 (CEST) Date: Thu, 11 Apr 2024 12:14:22 +0200 From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Subject: Re: [rfc] [patch] PR28204: debuginfod ima signature verification Message-ID: <20240411101422.GI1292@gnu.wildebeest.org> References: <437d21e98ce9c83d2c34cb2c1e13c5aa7af98c2e.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Frank, On Wed, Apr 10, 2024 at 05:01:36PM -0400, Frank Ch. Eigler wrote: > > > - to drop "permissive" mode > > > > We discussed a bit on irc about "wording". But I think it isn't really > > how it is worded, but that there is just different features. What is > > called "enforcing" is an authenticity scheme. While "permissive" is > > more like an (optional) error-detecting mode. IMHO it makes sense to > > simply separate those. > > For the record, on IRC, I presented these two additional arguments: > > > in the case of federated debuginfod servers, such as > debuginfod.elfutils.org, a user is stuck with "ignore" mode > operation, because not all upstream servers will have ima > signatures to pass. this sacrifices all possible assurance that > could come from the federated server relaying ima signatures from > those servers that have them > > even in non-federated cases such as fedoraproject.org, the ideal > case for "enforcing" mode as a default, it will fail the moment > the user happens to try to debug some pre-fedora-38 binary that > may be sitting on the system --- because those rpms just don't > have signatures available at all > > for both these scenarios, the original "permissive" mode would be > suitable > > > IOW, without a "permissive" mode being available at all, we could not > ask users to enable this new code at all for our own federated > servers, nor even for fedora. That's because no server can guarantee > the availability of signatures for all content they can serve. I don't understand why you say we cannot ask users to enable the ima checking code. Isn't the goal to make sure that the user only gets ima-signed/verified files for the distro they are debugging/analyzing on? Especially if a server can also provide non-verifiable files, then you would want to have strict checking to make sure. > > That way you don't have a authentication scheme that is easily > > defeated (when put in "permissive" mode). > > This "easily defeated" theory needs a threat model. It sounds like > you are thinking of > - an evil debuginfod instance that > - you trust enough to list in DEBUGINFOD_URLS > - but not enough to label it with "ima:enforcing" > - which may strip the X-DEBUGINFOD-FILE-SIGNATURE header" en route > then yeah, but sounds far-fetched rather than easy. I think I simply don't understand what the thread model is that ima:permissive guards against. It seems not to protect against the main thing you want to do ima checking for. You only want debuginfod-client to provide files that are signed and can be verified. > > And you can implement a simpler error-detection mode that can work > > in more cases (by using the executable .gnu_debuglink CRC) > > No, we already know that this is incapable of checking e.g. source > files. And there is no separate CRC for executables vs. debuginfo > files. And note that this provides zero protection in the same threat > model above (as the CRC field could be MITM'd). Sure. I guess if you don't enforce ima checking you can just rely on https. And it is kind of the point that this is similar to the threat model that "permissive" guards against (random, bit flipping, accidential replacement of files). Relying on https and CRC checking seems simpler to understand for that. But you are right that there isn't really anyhing for the main executables. For the source files you could check the lenght and time stamps (or the MD5 sums if added by the DWARF producer). > > [...] > > One "big picture" question is whether this should be a per server URL > > policy or something that is enabled/disabled for all server URLs? > > That makes it less "flexible" but should simplify things a bit for the > > user (and the server urls parsing). > > Blame some guy named Mark for getting Ryan to build that out last year. :-) > > https://sourceware.org/pipermail/elfutils-devel/2023q3/006299.html Sorry. I see back then I also didn't get use case for the "permissive" policy. But yes, it might have been a mistake to suggest different policies per URL/server. Cheers, Mark