This could be useful for SMB3 as well - good topic On Thu, Jan 25, 2018 at 1:11 PM, 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. > > 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 -- Thanks, Steve
