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

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Sun, 2018-01-28 at 23:50 -0500, Theodore Ts'o wrote:
> On Sun, Jan 28, 2018 at 10:39:10PM -0500, Mimi Zohar wrote:
> > At what point is the signature on the Merkle tree hash verified?  I
> > can't imagine it being done every time a page is read.  It must be
> > done and the result cached at file open.
> 
> Sorry, I misread your question.  The signature on the Merkle tree hash
> is verified the file is opened, and then validated Merkle tree hash is
> cached in the in-memory inode data structure.

Let's assume for the moment that there are valid, safe use cases for
fs-verity.  (Defining under which circumstances the fs-verity
integrity verification method is safe to use, is a separate
discussion.)

The LSM security_file_open hook is where fs-verity and IMA meet.  The
fs-verity Merkle tree hash signature would be another IMA-appraisal
integrity verification method.

For those that are interested in attesting to the measurement list or
including the file hash/signatures in the audit log, the same
mechanisms that currently exist would be in place for using the fs-
verity merkle tree signature.  The same mechanisms that are in place
for including file signatures in software packages could be re-used.

Bringing it all together, what is needed?
- the signature of the Merkle tree hash
- a method for validating the signature
- a method for knowing if fs-verity is enabled on the system
A mode where fs-verity can not be disabled on the local, running
system, once enabled.
- lastly, a policy.  Just because a file has a signature, does not
necessarily imply that it should be verified.

A decision was made years ago, at the time when LSMs "just" enforced
mandatory access control (MAC), that there would be a clear division
between integrity and MAC, totally independent of each other.  Today,
LSMs do other things than enforce MAC, but this separation still
exists.

With Matthew Garrett's patch set this division will continue to exist,
but will be blurred by an LSM calling the integrity subsystem
directly.

Mimi

> This is similar to how we cache the per-file key in fscrypt; once the
> key is derived, we keep it in the inode cache until the inode is
> dropped from the inode cache, or after a userspace request to revoke
> all keys derived from a user's login key (which is triggered when the
> user logs out of their ChromeOS session).
> 
> 							- Ted
>