On Thu, Mar 7, 2019 at 12:48 PM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Wed, 2019-03-06 at 20:19 -0800, Matthew Garrett wrote: > > 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. > > In an environment where the initramfs contains everything, including > the IMA policy, and is verified, then what you're saying is true - the > IMA policy doesn't need to be signed. However, the existing dracut > and systemd IMA modules read the IMA policy not from the initramfs, > but from real root. In this environment where the IMA policy is on > real root, an attacker could modify the IMA policy. I realize this is > an existing problem, not particular to "get_hash'. Unlike other > policy changes, the attestation server would have no way of detecting > this particular change. Ah, got you. Would measuring the policy be sufficient here? > > 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 call itself wouldn't be broken, but determining if the filesystem > is actually calculating/re-calculating the file hash properly or > simply returning a stored/cached value. I do see the benefit of the > filesystems being responsible for the file hash. Perhaps I'm just > being overly cautious. I'd like to hear other people's opinions. Yup, happy to get further feedback on this.
