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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2018-01-25 at 14:11 -0500, Theodore Ts'o 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.

How do you know the file is in this special format?  Would it be a per
filesystem flag (so every file) or selectable per-file by some other
mechanism.  If it's per-file, why not simply use the existing xattr
mechanism?

I'd have a big problem if it's not per-file because most of the cloud
use for IMA is enforcing immutability and tamper proofness of images
and not all files in an image can be immutable, so you only turn on
appraisal for some files.

However, if it is per-file, how do I tell from an offline backup which
files have the trees and which don't?

> 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 cost of this is presumably one hash per page in the tree, so it
costs quite a bit in terms of space.  Presumably the hash tree is also
dynamically resident meaning a page fault could now also potentially
fault in the hash tree, leading to a lot of sub optimal I/O patterns?

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

That's a bit unfair.  My next question was going to be why not just
make this an actual IMA mode (meaning you could choose to have a global
hash or a tree hash).  Does this mean that a-priori you've already
ruled out IMA integration because you don't want to work with the
developers?

> 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

PKCS11 is the standard for cryptokeys.  I presume you just mean a
message signing standard like PKCS7 or RFC 2315?

>  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.

I assume the "write" part of this is that the file must be deleted and
re-created?

James