On Tue, Jan 30, 2018 at 06:25:02PM -0500, Mimi Zohar wrote: > On Mon, 2018-01-29 at 18:02 -0500, Theodore Ts'o wrote: > > On Mon, Jan 29, 2018 at 07:09:01AM -0500, Mimi Zohar wrote: > > > > > > 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. > > > > I wasn't planning on using the file open hook for fs-verity at all, > > since the merkle hash signature is going to be cached in the per-file > > system inode --- e.g., for ext4, it would be stored in EXT4_I(inode), > > aka "struct ext4_inode_info". > > Ok, so if not at open, at what point do you plan on validating the > merkle hash signature? I said we would not using the LSM file_open hook. Instead it will be done in ext4_file_open() or f2fs_file_open(). That's because the place where the key is cached is in the file system specific portion of the inode. This is what I meant by EXT4_I(inode) aka struct ext4_inode_info. So it does happen at file open time; it just doesn't use the LSM file_open hook. One of the features of fs-verity is that it does *not* require the use of the LSM infrastructure. > I agree with you that the integrity architecture needs to be easily > extendsible to support different integrity authentication methods. > The list, below, is a set of fs-verity functions needed to be > exported for IMA. Hopefully I didn't miss anything. Just to be clear, who is signing up to do all of this work to enable fs-verity for IMA? In particular, if you and James are asking *me* to do all of this development work, when I have no need for any of these benefits, I'm going to have to decline the honor. I'm happy to try to modify the design to make it easier for IMA to use fs-verity. That's different from actually implementing it. > > So I want to support a very simple case where the policy is simply > > "the public key needed to verify the PKCS7 signing block is in a > > trusted keyring". > > Which trusted keyring? How is the keyring populated? What prevents > other keys from being added to that keyring? It will probably be a separate keyring, but in theory we could use the keyring used to validate signed kernel modules. There are a number of different ways the policy for signed kernel modules can be configured[1], and the same would be true for fs-verity. (The reason for a separate kernel keyring is to allow for a separation between those keys trusted to sign kernel modules, and those trusted to sign for fs-verity.) [1] https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/module-signing.html > So the implied policy is that no signatures will be verified unless > userspace turns the bit on. So you're trust is based in userspace. For the initial use case that we're interested in, yes. The check to make sure the verity bit is enabled for a small set of privileged APK's will be done by the AOSP userspace, and the AOSP userspace lives in a read-only system partition which is protected using dm-verity. (And the keys for dm-verity are protected using asigned bootloader; it is possible to do data integrity without using IMA/EVM, and millions and millions of Android devices are doing in this way.) The problem we're trying to solve is that in order to allow for the privileged APK's to be upgraded more frequently, they are stored in the /data partition, which is encrypted; however, fs-crypt does not provide data integrity guarntees. fs-verity allows us to protect those APK's (which are equivalent in power to software in the system partition, being privileged APK's). Note also that an APK will often have large number of translations that will never be used on a particular device, so doing full check of the entire APK will mean doing unneeded work. Obviously you have to trade off the time of doing sequential reads versus the random reads for doing on-demand Merkle tree checks, but if you have translation resources for Russian, Chinese, French, Spanish, etc, and the only language used on a particular device is English, then the on-demand checks can often be far more efficient, especially if the one of the figures of merit is how long it takes for an application to start painting the first pixel after the user clicks on its icon. > > If someone needs something more complex than the simple "key is in the > > trusted keyring", I'm happy to say that the right answer is to use the > > LSM hooks, and it should be straight forward to provide interfaces so > > that the LSM can determine that file system supports verity and the > > file has the verity bit set. The LSM could also apply additional > > restrictions (if the SELinux file type is supersekrit_t, then only a > > smaller set of keys will be allowed to be used to sign the PKCS7 > > signature block). > > Interesting, so there is an additional policy limiting which keys may > be used based on an LSM labels, if so desired. If someone implements it, yes. If there is a business case where the benefits outweighs the costs, and the headcount can be funded, it would happen. However, having spent time trying to understand the IMA/EVM/LSM/SELinux architecture, I've spent enough time to decide it's not something I would do on my own time, for fun. :-) - Ted
