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.
