[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 #17 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Ryan Goldberg from comment #16)
> (In reply to Mark Wielaard from comment #12)
> > In config/profile.csh.in and config/profile.sh.in the prefix variable is
> > explicitly set and no longer unset. Is that deliberate?
> Taking a look at both files they seem to still contain `unset prefix` as
> their last lines. Would that not do the trick?

Yes it would. I was just confused why it was needed.
But I now see that @sysconfdir@ is used and that uses $prefix.
So that explains why you need it defined.

> > In debuginfod_validate_imasig the file_data = malloc(data_len); depends on
> > the (externally) given file size. It is then read in one pread call. And the
> > whole buffer is then given to EVP_DigestUpdate. Note that this might create
> > a giant malloc buffer, which might trigger OOM. pread might succeed with
> > fewer bytes than given. It needs to be called in a loop. But it would be
> > better if we could read it and feed it to EVP_DigestUpdate in (small) chunks.
> Sure, just looked at the docs for EVP_DigestUpdate and seems like this
> change should be pretty straightforward.
> 
> > Is EACCESS the right error code to return when the signature couldn't be
> > checked/is invalid? That is the same as when we get
> > CURLE_REMOTE_ACCESS_DENIED. It might be good if it was an unique error code
> > so users can know that the file was not trusted.
> How do you feel about EPERM? Not exactly its usage but we've used up a good
> number of the more applicable ones with the CURL errors (EACCESS, EINVAL)

Yes, EPERM sounds like a good pick. It is unlikely to be produced by any other
operation (unless there are file seals in play).

> (In reply to Mark Wielaard from comment #14)
> > I think it is the user/distro packager who should decide which ima-certs to
> > ship. I don't think elfutils should come with ima-certs itself.
> From what I've seen finding the correct certificates for IMA verification
> has been pretty tricky, so distributing a copy of these (at least early
> certificates) might be a good idea. Eventually the intention is for these
> certs to be shipped in a known location which we can easily add to the
> search path, but until then having a copy seems like the best bet imho.
> 
> > Why is there a "permissive" policy? What is the use case for this?
> It might be that a user wants to be aware of what's going on but does not
> need to be quite so strict on rejection. Permissive won't allow incorrect
> signatures but will allow say an unsigned file whereas an enforcing client
> will reject anything that does not come with a valid signature

Doesn't that give a false sense of "security"?
It still rejects some stuff, but doesn't really protect against "falsifying"
files, all a server has to do is not provide an IMA 

If it is just to see what would happen if enabling ima file checking, then it
probably shouldn't reject anything. In that case it should warn for both
missing and invalid signatures, but still accept them.

But in general I like less "modes".

> > Should the policy be per debuginfod url? So you can point to an official
> > distro debuginfod which must be in enforcing mode, but can add a local one
> > with an "ignore" policy.
> I was thinking of keeping things simple, but don't have anything against
> moving to a per URL sort of approach. What kind of format would you want for
> such a thing? For urls foo:bar:baz would we want something like
> ignore::enforcing where blanks are the default? Don't love this structure
> since it seems a little unwieldy. I'll think on a better format for it.

Maybe prefixing or postfixing URLS with + or adding the name of the cert?
DEBUGINFOD_URLS="https://debuginfod.fedoraproject.org/+FEDORACERTNAME" ?

Yeah, gets ugly quick :{
But I think a common use case will be having the main distro debuginfod server
in enforcing mode and your local/org debuginfod server in trusting mode.

-- 
You are receiving this mail because:
You are on the CC list for the bug.