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". > 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). 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.) > 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". 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). Is this sufficient to allow fs-verity the ability to use IMA, if the policy so requests it? - Ted P.S. I should note that we already have examples of data integrity functionality that doesn't go through security/integrity. I refer you to diginally signed kernel modules (which do not use IMA), or dm-verity (also not mediated through IMA). And the existence of data integrity functions that don't use security/integrity has not caused the security programmers union to show up and break knuckles, just as the Teamsters Union might have done if they had discovered that programmers were carrying networking gear into Interop (back when it was in San Jose) without being accredited union members. My original intent was for fs-verity to be much like dm-verity. That is, something simple doesn't require a huge policy machinery just to use it. If others are interested in using fs-verity in a much more complex way, or as part of a Rube Goldberg arrangement of security modules and policies, that's fine. I just want that mode to be optional.
