[Bug debuginfod/28204] extend webapi / verification with forthcoming signed-contents archives

["mark at klomp dot org" <sourceware-bugzilla@sourceware.org>]

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.