On Sun, Feb 10, 2019 at 09:06:55AM -0500, Mimi Zohar wrote: > For which files will the Merkle tree be created? Is this for all > files on a per file system basis? Or is there some sort of "flag" or > policy? The original design was based on an ioctl enabling/disabling > a flag. In this new design, is there still an ioctl? So for our first use case, it will be used for "privileged APK files" in Android. You can think of this as a "setuid binary", effectively. The Merkle tree hash is digitally signed and provided by the App Store. It is *not* calculated on the android device. So not all files will have Merkle trees, because storing the android device won't have access to the signing key. The enforcement is done by the userspace code which is loading the privileged APK (the application loader). If the APK is privileged, then it must have the Merkle tree, with the root hash matching the digitally signed hash. Otherwise, the application loader will refuse to load it as a privileged "root" application. For Android, the policy enforcement is done in userspace (should the APK be privileged), because userspace loads the APK. We just let the kernel take care of verifying the blocks as they are read, and that's done by fsverity. If we wanted to do something similar with all setuid executables, that would have to be enforced via some kind of LSM (e.g., a SELinux policy). > The existing file hashes included in the measurement list and the > audit log, are currently being used for remote attestation, forensics > and security analytics. IMA has a very different set primary use cases than fsverity. As you have pointed out, forcibly dragging the entire file into the page cache to measure it can sometimes result in performance improvements. So there may be system administrators that would prefer having the entire file measured up front. On the other hand, if the binaries/APK's are gargantuan, and not all of the file will be used (perhaps there are translation files, audio/video assets, etc., that aren't used most of the time), then only verifying the blocks that are used will be a better approach. I've never thought that fsverity should replace IMA or vice versa; they are optimized for different things. If it makes sense in some configuration for IMA to use the fsverity Merkle tree root hash as a measurement, it's easy enough to set up the hooks so they can be provided to IMA for its use. This might be the easist way to integrate with SELinux, for example. Regards, - Ted
