On Wed, 2019-03-06 at 15:36 -0800, Matthew Garrett wrote: > > But they would have to knowingly add "get_hash" to the IMA policy and > > have signed it. > > But in the non-signed case they'd still need to knowingly add > "get_hash" to the IMA policy. Why does signing indicate stronger > understanding of policy? Nobody is suggesting that signing the policy is a stronger indication of understanding the policy. Signing the policy simply limits which policies may be loaded. > If my understanding of ima_match_policy() > correct, if there's already a measurement rule that applies to a > filesystem then adding an additional trust_vfs rule will be ignored, > so once the initial policy is loaded it's not possible for someone to > transition a filesystem from a full read to using the vfs call. IE, a > policy like: > > measure > measure fsmagic=0x46555345 trust_vfs > > is still going to perform the full measurement even on FUSE. This scenario assumes that a custom policy has already been loaded and that there are default catchall rules. I really do hope that anybody enabling support for loading multiple policies requires those policies to be signed, like the builtin appraise policy. > > > > I'm happy to add this if there's a real threat model around it, but > > > requiring signing for something other than security reasons seems like > > > it's conflating unrelated issues. > > > > A colleague said, relying on the filesystem to provide the file hash > > extends the TCB to include filesystems. > > The TCB already includes filesystems - IMA's measurements are only > accurate if the filesystem returns the same data on subsequent reads > (assuming i_version hasn't been updated). We assert that this is true, > but it the filesystem is outside the TCB then that assertion is > invalid. There is also a difference between trusting the filesystem "read" and the filesystem "get_hash" implementation, that have yet to be written. Mimi
