On Wed, Mar 6, 2019 at 5:54 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > 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. I'm not sure I understand the additional risk, though. Either a filesystem is already being measured using a full read, in which case adding an additional rule won't change behaviour, or it's not being measured at all, in which case there's no incentive for an attacker to add a new rule. > > > > 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. In both cases we're placing trust in the filesystem's correctness. It's certainly possible for the get_hash call to be broken, but that's something we can put additional testing into. The same argument implies that enabling appraisal is increasing the amount of trust we place in the filesystem - without it we don't need getxattr() to work, and without digital signatures we don't need the kernel's RSA code to work. Most new features result in us relying on more code, and in some cases we're not even able to audit that code (eg, if you're not using an encrypted filesystem then we're depending on the correctness of your disk's firmware, and we know that there are implementations that don't verify updates or which provide debug commands that allow modification at runtime in a way that could be used to defeat IMA)
