From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B6C613858C53; Sat, 26 Aug 2023 22:25:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B6C613858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1693088720; bh=qVheB4rzJRtUOkTwKZmXlYlOXxp3vCGHCBylQbUAaAs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bgscT38B3VfsUNJPl0vvaP4A7xMQWaXgB9d4MlibsdT92wb/wICHagrvTkhmctJcK cnN/szsAX19c3dCPhfN9CU0vNXiq/JMsIjISKTqjkQaJeQYKeDOIrms/dVBJJtjz+5 rZxlsRKuEQoUu6KoBZWIIpJocGWQ9mYT5IQld0GQ= From: "mark at klomp dot org" To: elfutils-devel@sourceware.org Subject: [Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives Date: Sat, 26 Aug 2023 22:25:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: elfutils X-Bugzilla-Component: debuginfod X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at klomp dot org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rgoldber at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28204 --- Comment #26 from Mark Wielaard --- (In reply to Ryan Goldberg from comment #23) > (In reply to Mark Wielaard from comment #22) > > This still feels odd. Since you cannot distinguish between non-sig f36 > > package (okish?) and non-sig f38 packages (bad?). I think you have to e= ither > > trust or reject all non-sig packages from such a server. > I see where you're coming from but what policy would you use for > https://debuginfod.fedoraproject.org? I think that depends on which release I am using. Normally I would be debugging/profiling local programs/libraries. So for f38 I would like to a policy that checks the ima signatures. If I am on f36 or if e.g. I expect to be inspecting a non-local core file b= ased on f36 then I would not use a policy that checks the ima signatures, because they might not be there. > > I'll look at the code to see if I understand what this means in practic= e. > > Are those the messages presented to the user (in verbose mode? always?)= . And > > does this mean all three cases warn (or only the second and third)? And= is > > it just a message or does it also mean actual rejection in some cases? > > 2008 if(NULL !=3D url_ima_policies && ignore !=3D url_ima_policies[comm= itted_to]) > 2009 { > 2010 int result =3D debuginfod_validate_imasig(c, target_cache_tmppat= h, fd); > 2011 if(0 =3D=3D result) > 2012 { > 2013 if (vfd >=3D 0) dprintf (vfd, "the signature is valid\n"); > 2014 } > 2015 else if(EINVAL =3D=3D result || enforcing =3D=3D url_ima_policie= s[committed_to]) > 2016 { > 2017 // All invalid signatures are rejected. > 2018 // Additionally in enforcing mode any non-valid signature is r= ejected, so by reaching > 2019 // this case we do so since we know it is not valid. Note - th= is not just invalid signatures > 2020 // but also signatures that cannot be validated > 2021 if (vfd >=3D 0) dprintf (vfd, "ALERT: this download is being r= ejected since the IMA signature could not be verified\n"); > 2022 rc =3D -EPERM; > 2023 goto out2; > 2024 } > 2025 else > 2026 { > 2027 // By default we are permissive, so since the signature isn't = invalid we > 2028 // give it the benefit of the doubt > 2029 if (vfd >=3D 0) dprintf (vfd, "the signature could not be veri= fied\n"); > 2030 } > 2031 } > > Here is the relevant snippet Thanks. So if the policy is "ignore" nothing is checked. Otherwise the ima signature is checked. If the policy is enforcing we return EPERM. Otherwise we return the target/OK, independent of the result of the ima sig check. All notices are printed if we are in verbose mode. BTW. The last notice isn't really accurate. The signature might have been verified. In which case it was invalid. In practice "permissive" (or default) mode is no different from "ignore". Which imho makes permissive mode not very useful. So I think we shouldn't have a permissive mode, just use ignore. If we have an permissive mode then I think it should work like the selinux permissive mode. That is, it should always check the signature, but instead of failing with EPERM, it should always produce a warning (whether or not we are in verbose mode or not). --=20 You are receiving this mail because: You are on the CC list for the bug.=