[PATCH v3 4/4] fuse: define the filesystem as untrusted
zohar at linux.vnet.ibm.com
Thu Mar 15 21:24:07 UTC 2018
On Wed, 2018-03-14 at 15:53 -0700, Michael Halcrow wrote:
> 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
> 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.
Next steps should also include identifying methods for storing and
transporting the Merkle tree signature without having to read the
entire file for remote filesystems.
With this fs support, signed files on file systems mounted with the
SB_I_IMA_UNVERIFIABLE_SIGNATURE flag would then be verifiable.
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
More information about the Linux-security-module-archive