[LSF/MM TOPIC] fs-verity: file system-level integrity protection

[Theodore Ts'o <tytso@mit.edu>]

I'd like to talk about a proposal to implement and upstream something
that we've been calling fs-verity, which is something like dm-verity,
but implemnted on a per-file basis.  It will be implemnted much like
fs/crypto, in that most of the code will be in a generic layer, with
minimal modifications needed in the file system layer.

The merkle tree will be located after file's normal data, and then
after the package manager sets the verity bit, i_size will be updated
so that the fs-verity header and merkle tree will be "hidden" from
userspace and the file will become immutable.

How does this differ from IMA's file integrity?

*) The pages are verified as they are read, so pages are verified as
they are read the storage device; this avoids a large latency hit when
the file is first opened or referenced.

*) The design and code are done by file system developers, so it
doesn't have the locking problems of the IMA code.

The initial use case of this will be for Android, where the latency
concerns of doing the full checksum at file open time is important.

In the future, the fact that a file has been signed using fs-verity,
using a PKCS 11 signature with a key on a trusted keyring (possibly
the same one used for signed kernel modules, or perhaps a separate
keyring) could be used as input into a security policy which requires
this for say, setuid executables, setuid shell scripts, etc.

Most of this feature could also be used with a non-cryptographic
checksum to provide data checksums for read-only files in a general
way for all file systems.  It wouldn't be as flexible as btrfs, but
for files being stored for backup purposes, it should work quite well.

  	       	   	  	       	      - Ted