[PATCH v3 4/4] fuse: define the filesystem as untrusted

[mhalcrow@google.com (Michael Halcrow)]

On Wed, Mar 14, 2018 at 04:42:51PM -0500, Eric W. Biederman wrote:
> In this case I mean trust as in the believe that the server is not
> actively trying to subvert the guarantees that IMA is depending
> upon.

The fs-verity adversarial model we're targeting includes a malicious
layer backing the local file system inode's page cache.

For example, the malicious layer can be a drive controller with
trojaned firmware or a compromised remote server.

> What happens if the server on the first read returns an innocuous
> file that matches it's ima xattr, but on the next read of the file
> returns an evil trojan horse.  Or what if the server implements a
> cache coherency protocol but lies and does not report all of the
> changes to a file.

fs-verity validates each page in the inode's page cache against the
inode's root-of-trust every time the page is read into the cache.

The signature mechanism on the root-of-trust must bind the inode
identity.

The initial version of fs-verity supports Secure Boot, and the TCB
validates each inode identity in the mount during the boot process.
fs-verity does this via an ioctl that provisions the fs-verity
measurement, causing the inode (along with its immutable measurement)
to be pinned by the superblock for the life of the mount.  This meets
requirements for the Android platform's use case, which only needs to
cover about 15 APKs during boot.

This doesn't scale.  Future work will include integration with PKCS7
and/or IMA.  Signatures will be dynamically verifiable against a key
or keys in the TCB, and I'd like to establish a safe way to avoid
having to pin inodes and their measurements.
--
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