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? > > 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. > > This is *your* set of requiremnets, not mine. If it's easy to do, > that's fine. But if it doesn't, piling on extra requirements which > fs-verity can't meet is not a proof of fs-verity being not fit for > purpose, at least some use cases (e.g,. the ones we are envisioning > for fs-verity). That didn't sound like requirements to me, but more a benefit statement. > Again, I'm not the one arguing for IMA/fs-verity integration, and > while I am happy to work with IMA if at all possible, I am *not* > interested in compromising the fs-verity use case, or adding vast > amounts of complexity to fs-verity just to confirm to the IMA > architecture. (That is, any complexity will need to be in optional > userspace components, such as what I've been discussing with James to > support his docker use case, or in the security/integrity subtree. I > really *don't* want to deal with unnecessary complexity into fs/ext4, > fs/f2fs, or fs/verity.) 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. > > 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. > > 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? 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. > 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. > Is this sufficient to allow fs-verity the ability to use IMA, if the > policy so requests it? - A function to verify that the kernel supports and is currently enforcing verity. - A function to know if the file is in policy and has a signature. Different return codes. - A function to force re-validation of the file signature. - Access to the signature, wherever it might be stored, for inclusion in the measurement list and audit log. (- Possibly access to the public keys for the remote attestation server.) Mimi
