On Wed, Oct 18, 2023 at 12:07 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > 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. I mentioned tmpfs because as you said, it's listed in the ima_tcb policy as dont_measure. I'm not sure why since according to the man page https://man7.org/linux/man-pages/man5/tmpfs.5.html it does support xattrs: > The tmpfs filesystem supports extended attributes (see xattr(7)), > but user extended attributes are not permitted. Maybe tmpfs can be removed from the dont_measure list? > > > 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 > Thanks for working on a fix! Raul
