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 6B01E384AB5E for ; Tue, 14 May 2024 15:18:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B01E384AB5E 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 6B01E384AB5E 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=1715699926; cv=none; b=UULct+DtRhsaHPaRmuQaU9YEtf+aI4TXq2mw5yG7Dmxl3chJb8LNmTvHdNpC7GsXgkd+2v3uByNvaoF6Uaw/EIGTAx06rRne3y4QQAXu04dx3wj+b9ZdTqobl3J4g5XLE540kNrWA/UolPBJ4KXLSPPChW090eCwWPoxlsC07wg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715699926; c=relaxed/simple; bh=7MZgb8WKghjixeF36VlGJTZ3qnpFHkutPmADWIr75xo=; h=Message-ID:Subject:From:To:Date:MIME-Version; b=CwB/AE+zwXpNBY23BpHwyGBBIrKwb0PWHF0xSlgqcJB3XFV9TLl7ivW47fT6rFXMDy2DVXEh3qdRNWiojvemFh5XS57MWpEDhALqkjbYxXBkZQ7DFxs5ZbxNBZzbt/uHztJjjbzwLlhcks+B0b2nOj7zq7/LdPkT66DS35ej2EQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 63E1A3031F64; Tue, 14 May 2024 17:18:44 +0200 (CEST) Received: by r6.localdomain (Postfix, from userid 1000) id 2904C34053C; Tue, 14 May 2024 17:18:44 +0200 (CEST) Message-ID: Subject: Re: [rfc] [patch] PR28204: debuginfod ima signature verification From: Mark Wielaard To: Aaron Merey , "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Date: Tue, 14 May 2024 17:18:44 +0200 In-Reply-To: References: <437d21e98ce9c83d2c34cb2c1e13c5aa7af98c2e.camel@klomp.org> <20240416221500.GA8994@redhat.com> <20240505013003.GA1291@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.1 (3.52.1-1.fc40) MIME-Version: 1.0 X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,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 Aaron, On Thu, 2024-05-09 at 13:56 -0400, Aaron Merey wrote: > I know there's already been a lot of discussion re. ima:permissive and > I'm weighing in rather late, but FWIW I do support including it. > Currently individual ELF sections cannot be downloaded when > ima:enforcing is active. With ima:permissive we could support proper > section queries while also being able to perform some amount of > ima verification. But what would "some amount of ima verification" mean? I think we (me included, for suggesting some of it in the first place) made things way to complicated by supporting multiple different ima certificates and then also splitting ima verification policy per server URL. If we also add different policies for the "amount" of ima we do then it because really hard to reason about imho. We should probably take a step back and formulate the security attack we are trying to defend against with ima verification first. Cheers, Mark