On Wed, 2023-10-18 at 10:35 -0600, Raul Rangel wrote: > > > > Instead of reverting the patch, perhaps allow users to take this risk > > > > by defining a Kconfig, since they're aware of their policy rules. > > > > > > > > > > That sounds good. Or would it make sense to add an option to the > > > policy file? i.e., `verifiable fsmagic=0x794c7630 > > > > Perhaps instead of introducing a new "action" (measure/dont_measure, > > appraise/dont_appraise, audit), it should be more granular at the > > policy rule level. > > Something like ignore_cache/dont_ignore_cache, depending on the > > default. > > > > Eric, does that make sense? > > I guess if one of the lower layers was a tmpfs that no longer holds. I don't understand what's special about tmpfs. The only reason the builtin "ima_tcb" policy includes a "dont_measure" tmpfs rule is because the initramfs doesn't support xattrs. > Can overlayfs determine if the lower file is covered by a policy > before setting the SB_I_IMA_UNVERIFIABLE_SIGNATURE flag? This way the > policy writer doesn't need to get involved with the specifics of how > the overlayfs layers are constructed. A read-only filesystem (squashfs) as the lower filesystem obviously does not need to be re-evaluated. With the "audit" and perhaps "measure" rule examples, the policy can at least be finer grained. > In the original commit message it was mentioned that there was a more > fine grained approach. If that's in the pipeline, maybe it makes sense > to just wait for that instead of adding a new keyword? We just revered > this patch internally to avoid the performance penalty, but we don't > want to carry this patch indefinitely. I'm not aware of anyone else looking into it. Mimi
