Hi - > > IOW, without a "permissive" mode being available at all, we could not > > ask users to enable this new code at all for our own federated > > servers, nor even for fedora. That's because no server can guarantee > > the availability of signatures for all content they can serve. > > I don't understand why you say we cannot ask users to enable the ima > checking code. Isn't the goal to make sure that the user only gets > ima-signed/verified files for the distro they are debugging/analyzing > on? Especially if a server can also provide non-verifiable files, then > you would want to have strict checking to make sure.
The goal of dealing with 100% verified files is nice in theory, but the question is what to do with the exceptions. We know there will be exceptions (when debugging older binaries, or when the server has a hickup, or when debugging other distro's binaries from a container, or ...). In the absence of a "permissive" type mode, those exceptions result in a failure. Curing those requires the user to turn off signature checking entirely and restart whatever servers/clients are affected. > [...] I think I simply don't understand what the thread model is > that ima:permissive guards against. In the absence of deliberately hostile servers that would strip X-DEBUGINFOD-FILE-SIGNATURE, this mode provides ima:enforcing level security for those servers & files that have verifiable info and ima:ignore level (non) security for those that don't. It's as if DEBUGINFOD_URLS="ima:enforcing HTTP:FOO ima:ignore HTTP:FOO" except that cannot work with the current client code (because of parallelism tie-breaking & dupe elimination). > It seems not to protect against the main thing you want to do ima > checking for. You only want debuginfod-client to provide files that > are signed and can be verified. No, I am not so absolutist with the goal. "Best effort" would be my default. If you wish to use only ima:enforcing, you'd be welcome to. > > > And you can implement a simpler error-detection mode that can work > > > in more cases (by using the executable .gnu_debuglink CRC) > > > > No, we already know that this is incapable of checking e.g. source > > files. And there is no separate CRC for executables vs. debuginfo > > files. And note that this provides zero protection in the same threat > > model above (as the CRC field could be MITM'd). > > Sure. I guess if you don't enforce ima checking you can just rely on > https. And it is kind of the point that this is similar to the threat > model that "permissive" guards against (random, bit flipping, > accidential replacement of files). [...] It is "similar" but strictly less protective. > > > [...] > > > One "big picture" question is whether this should be a per server URL > > > policy or something that is enabled/disabled for all server URLs? > > > That makes it less "flexible" but should simplify things a bit for the > > > user (and the server urls parsing). > > > > Blame some guy named Mark for getting Ryan to build that out last year. :-) > > > > https://sourceware.org/pipermail/elfutils-devel/2023q3/006299.html > > Sorry. I see back then I also didn't get use case for the "permissive" > policy. But yes, it might have been a mistake to suggest different > policies per URL/server. A single global policy setting would be even worse, without an available "permissive" setting. It would not be possible to handle exceptions without a reconfiguration/restart. - FChE
