> > > On the flip side when it really is a trusted mounter, and it is in a > > > configuration that IMA has a reasonable expectation of seeing all of > > > the changes it would be nice if we can say please trust this mount. > > > > IMA has no way of detecting file change. This was one of the reasons > > for the original patch set's not using the cached IMA results. > > > > Even in the case of a trusted mounter and not using IMA cached > > results, there are no guarantees that the data read to calculate the > > file hash, will be the same as what is subsequently read. In some > > environments this might be an acceptable risk, while in others not. > > So for the cases where it's not, there should be an IMA option or policy > to say any SB_I_IMA_UNVERIFIABLE_SIGNATURES mounts should be not > trusted, with the default being both SB_I_IMA_UNVERIFIABLE_SIGNATURES and > SB_I_UNTRUSTED_MOUNTER must be true to not trust, right? Right. To summarize, we've identified 3 scenarios: 1. Fail signature verification on unprivileged non-init root mounted file systems. flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES and SB_I_UNTRUSTED_MOUNTER (always enabled) 2. Permit signature verification on privileged file system mounts in a secure system environment. Willing to accept the risk. Does not rely on cached integrity results, but forces re-evaluation. flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES, not SB_I_UNTRUSTED_MOUNTER or IMA_FAIL_UNVERIFICABLE_SIGNATURES (default behavior) 3. Fail signature verification also on privileged file system mounts. Fail safe, unwilling to accept the risk. flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES and IMA_FAIL_UNVERIFIABLE_SIGNATURES Enabled by specifying "ima_policy=unverifiable_sigs" on the boot command line. Mimi
