From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.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 [thread overview]
Message-ID: <bug-28204-10460-zAZr6nmM66@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-28204-10460@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=28204
--- Comment #26 from Mark Wielaard <mark at klomp dot org> ---
(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 either
> > 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 based
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 practice.
> > 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 != url_ima_policies && ignore != url_ima_policies[committed_to])
> 2009 {
> 2010 int result = debuginfod_validate_imasig(c, target_cache_tmppath, fd);
> 2011 if(0 == result)
> 2012 {
> 2013 if (vfd >= 0) dprintf (vfd, "the signature is valid\n");
> 2014 }
> 2015 else if(EINVAL == result || enforcing == url_ima_policies[committed_to])
> 2016 {
> 2017 // All invalid signatures are rejected.
> 2018 // Additionally in enforcing mode any non-valid signature is rejected, so by reaching
> 2019 // this case we do so since we know it is not valid. Note - this not just invalid signatures
> 2020 // but also signatures that cannot be validated
> 2021 if (vfd >= 0) dprintf (vfd, "ALERT: this download is being rejected since the IMA signature could not be verified\n");
> 2022 rc = -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 >= 0) dprintf (vfd, "the signature could not be verified\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).
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2023-08-26 22:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-06 21:11 [Bug debuginfod/28204] New: " fche at redhat dot com
2021-08-12 18:13 ` [Bug debuginfod/28204] " fche at redhat dot com
2021-08-26 20:53 ` mark at klomp dot org
2021-09-08 11:26 ` fche at redhat dot com
2022-06-10 17:19 ` fche at redhat dot com
2022-07-13 19:44 ` rgoldber at redhat dot com
2022-07-14 16:32 ` fche at redhat dot com
2022-07-27 14:52 ` mark at klomp dot org
2022-08-04 19:45 ` rgoldber at redhat dot com
2022-10-20 21:10 ` mark at klomp dot org
2022-10-20 23:11 ` mark at klomp dot org
2023-07-06 19:49 ` rgoldber at redhat dot com
2023-07-23 21:05 ` mark at klomp dot org
2023-07-23 21:07 ` mark at klomp dot org
2023-07-23 21:08 ` mark at klomp dot org
2023-07-23 21:57 ` mark at klomp dot org
2023-07-23 22:23 ` mark at klomp dot org
2023-07-31 14:27 ` rgoldber at redhat dot com
2023-08-02 16:37 ` mark at klomp dot org
2023-08-07 17:04 ` fche at redhat dot com
2023-08-09 18:17 ` rgoldber at redhat dot com
2023-08-17 15:39 ` mark at klomp dot org
2023-08-17 16:25 ` rgoldber at redhat dot com
2023-08-25 15:00 ` mark at klomp dot org
2023-08-25 15:21 ` rgoldber at redhat dot com
2023-08-25 15:24 ` mark at klomp dot org
2023-08-25 16:43 ` mark at klomp dot org
2023-08-26 22:25 ` mark at klomp dot org [this message]
2023-08-28 14:40 ` rgoldber at redhat dot com
2023-08-29 13:09 ` mark at klomp dot org
2024-06-03 15:28 ` fche at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-28204-10460-zAZr6nmM66@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=elfutils-devel@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).