> On Jan 25, 2018, at 11:11 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > 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. I’m interested in this topic, specifically how we can support binary signing of executable code stored in NFS files. > 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. I’m not expert by any means, but this is also different than IMA in that it avoids the use of a trusted extended attribute. The NFS protocol has no support for system/trusted xattrs, currently. However, I suspect each file system might prefer to store the tree in its own way. And distributed file systems will have the additional challenge of protecting this metadata as it is in flight from file server to client. > 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. This is also interesting for NFS, which typically reads files by page, rather than by pulling all of a file to the client. > *) 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
