On Wed, 2018-01-31 at 11:05 -0500, Theodore Ts'o wrote: > 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 see. So anyone else adding security features is required to use the LSM hooks, but your use case is different? (rhetorical statement) > > 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. As long as you provide the fs-verity functions as previously discussed, I'll do the integration. > > > 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. The .builtin_trusted_keys only contains keys that are built into the kernel. With secure boot enabled, there is a signature chain of trust up to the running OS. Since the kernel is signed, the keys embedded in the kernel are part of this signature chain of trusted. These embedded keys become the new root of trust for the running OS. We can extend this signature chain of trust by requiring keys to be signed by a key on the .builtin_trusted_keys, before adding the key to another trusted keyring. If you are interested in extending the secure boot signature chain of trust to your keyring, you would create the trusted keyring specifying "restrict_link_by_builtin_trusted and include a signing key to the builtin keyring. Then you can safely load your signed fs-verity key from userspace, define a new fs-verity key, and black list the old fs-verity key, by adding it to the system blacklist keyring. > 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.) Sure. For this reason, IMA defined a separate trusted keyring. > [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. I think we already benched the discussion as to the level of security/integrity fs-verity provides; and in which use cases it can be safely used. > > > 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. :-) I understand you have lots of experience reading and understanding kernel code, but understanding another subsystem, without ever having been involved, no matter how well written that code is, takes time to understand. There is some really well written code in the security tree, especially considering the constraints put on it. Mimi
