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