From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elastic.org (elastic.org [96.126.110.187]) by sourceware.org (Postfix) with ESMTPS id 5B386384AB63 for ; Wed, 10 Apr 2024 21:01:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B386384AB63 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=elastic.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=elastic.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5B386384AB63 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=96.126.110.187 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712782908; cv=none; b=Zzh9Vb3QeZhQ6vwcrXh8cuYWSv6+EomvcrksAM/nGaVy4H7hf+BJKDViKSO9ARC6FDodYPTlS+M4IHnv/pt25qgJnH1xilsUM3k0ouzHZGg6T2MW5vcIN5cN+2/bTG7Bdb7ueBNkdJD0e0whJY/a6A9jDrnhyvT+HYhsSIn97Hg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712782908; c=relaxed/simple; bh=6HqzBusIkg8NCJZtXIc0SoEtNpgVPsG45wCm3liHziw=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=qLRJNdc8MngiZz1xV6MLYDzx0zrKQk3Pvy/BWcFe2wLxtdGGbgFOLkOlWC/Oc8X+XTNFGO7KxwU12f7bdHK6J5OaQ6gvLwobDGXmDW1/OZ498IrB/ryXgec6xpryBVdcurRUXcblIDDUvJdOXugGGOcdg9fbb0gK2zwDdNEJZyc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=elastic.org ; s=default2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MaWgRpbmHgixZLKe9LKG3gSGVkVaL/Ht2ZHG6NOit8E=; b=LOONZ1X49w3BAORhR5WxjAXo5+ VlEwE06/rYJI5zpnj1MQZ2nC0ycK9YCAZsiR6rb9rfmUaHasoQRoKVJ3A5/yjao7ltFppsqUgRKY1 BkohRfcGoc9OWdjKuod0Dv+iItb8czptI0B/omuBKFr0sBJJMUFZUMdSUA8M5/QINMUR6+8GfLmk7 pFuDbTrPMXfjrpBZBhUIu2CATkH+kdIeg1SKVGW5xFl3vr88BImfvgSRRkLvPkZcyO6i9A7nRW2bI LvgwfvF291vJZr6+rCitTWPOda9dObMPKwDdu1bUjI+PEahPXiO6WGd/sPwDWQfZtKlU/xehShn+d fggVfvKw==; Received: from vpn-home.elastic.org ([10.0.0.2] helo=elastic.org) by elastic.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1ruf4a-0000000030e-3SiI; Wed, 10 Apr 2024 21:01:36 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.97.1) (envelope-from ) id 1ruf4a-00000000TrC-1v4F; Wed, 10 Apr 2024 17:01:36 -0400 Received: from fche by very.elastic.org with local (Exim 4.97.1) (envelope-from ) id 1ruf4a-00000004Zml-1fHz; Wed, 10 Apr 2024 17:01:36 -0400 Date: Wed, 10 Apr 2024 17:01:36 -0400 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: [rfc] [patch] PR28204: debuginfod ima signature verification Message-ID: References: <437d21e98ce9c83d2c34cb2c1e13c5aa7af98c2e.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437d21e98ce9c83d2c34cb2c1e13c5aa7af98c2e.camel@klomp.org> X-Sender-Verification: "" X-Spam-Status: No, score=-102.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,USER_IN_WELCOMELIST,USER_IN_WHITELIST autolearn=ham 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, Mark - > > - 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. > 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. > 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). > [...] > 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 > Also is this all rpm/koji specific? Or do other distros also use ima > signatures, but encode/store them differently? As far as I know, Fedora/RHEL are the first. Yeah it's all package/style specific. > [...] > We now also have a fish profile. I'm afraid I don't speak fish. :-) > > +debuginfod_ima_verification_enabled="no" > > +if test "$enable_ima_verification" = "xrpmimaevmcrypto"; then > > + debuginfod_ima_verification_enabled="yes" > > + default_ima_cert_path=`eval echo "/etc/keys/ima:/etc/pki/rpm-ima:$sysconfdir/debuginfod/ima-certs"` # expand $prefix too > > + AC_DEFINE([ENABLE_IMA_VERIFICATION], [1], [Define if the required ima verification libraries are available]) > > + AC_DEFINE_UNQUOTED(DEBUGINFOD_IMA_CERT_PATH_DEFAULT, "$default_ima_cert_path", [Default IMA certificate path]) > > +fi > > +AM_CONDITIONAL([ENABLE_IMA_VERIFICATION],[test "$enable_ima_verification" = "xrpmimaevmcrypto"]) > > + > > Not all these are needed anymore now are they? > [...] The elaborate default_ima_cert_path? Yeah probably not, just force Fedora etc. to use the configure parameter. The AM_CONDITIONAL "xrpmimaevmcrypto" part? Yeah we need those. (The iamevm part is just for the headers.) At some point, I'd like to reformat the debuginfod code base, it's become a bit of a mishmash. Separate commit later, I guess? - FChE