Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> writes: > On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: >> Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> writes: >> >> >> > > 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. >> >> There is another scenaro. >> 4. Permit signature verification on out of kernel but otherwise fully >> capable and trusted filesystems. >> >> Fuse has a mode where it appears to be cache coherent, and guaranteed to >> be local. AKA when fuse block is used and FUSE_WRITEBACK_CACHE is set. >> That configuratioin plus the the allow_other mount option appear to >> signal a fuse mount that can be reasonably be trusted as much as an >> in-kernel block based filesystem. >> >> That is a mode someone might use to mount exFat or ntfs-3g. >> >> As all writes come from the kernel, and it is safe to have a write-back >> cache I believe ima can reasonably verify signatures. There may be >> something technical like the need to verify i_version in this case, >> but for purposes of argument let's say fuse has implemented all of the >> necessary technical details. >> >> In that case we have a case where it is reasonable to say that >> SB_I_IMA_UNVERIFIABLE_SIGNATURES would be incorrect to set on a fuse >> filesystem. >> >> Mimi do you agree or am I missing something? > > This simply sounds like a performance improvement to the second > scenario, where instead of *always* forcing re-validation, it checks > the i_version. Perhaps based on a different flag. As I understand the second scenario SB_I_IMA_UNVERIFIABLE_SIGNATURES is set, which implies that the filesystem is lacking something for IMA to reliably know when a file has changed. AKA a technical deficiency. The fourth scenario is the case when SB_I_IMA_UNVERIFIABLE_SIGNATURES can be legitimately be cleared, because the filesystem provides all of the necessary support for IMA to reliably know when a file has changed. My point is that cases exists or it is straight forward to implemented in fuse. I add the fourth case so that we can get a solid definition of SB_I_IMA_UNVERIFIABLE_SIGNATURES. Eric
