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

[ebiederm@xmission.com (Eric W. Biederman)]

Mimi Zohar <zohar@linux.vnet.ibm.com> writes:

> On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote:
>> Mimi Zohar <zohar@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.

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