[PATCH v1 1/2] ima: fail signature verification on untrusted filesystems

[Mimi Zohar]

On Wed, 2018-02-21 at 17:12 -0600, Eric W. Biederman wrote:
> Mimi Zohar <zohar at linux.vnet.ibm.com> writes:
> 
> > On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote:
> >> Mimi Zohar <zohar at linux.vnet.ibm.com> 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.

The information might be there, but IMA currently detects a file
change and resets the flags only when the last writer calls
__fput().  Any other time, new support would be needed.

Mimi

> 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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html