Mimi Zohar [off-list ref] writes:

On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote:

quoted

Mimi Zohar [off-list ref] writes:

quoted

quoted

quoted

quoted

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