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 >
