On Thu, Oct 11, 2018 at 8:22 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Thu, 2018-10-04 at 13:30 -0700, Matthew Garrett wrote: > > IMA wants to know what the hash of a file is, and currently does so by > > reading the entire file and generating the hash. Some filesystems may > > have the ability to store the hash in a secure manner resistant to > > offline attacks (eg, filesystem-level file signing), and in that case > > it's a performance win for IMA to be able to use that rather than having > > to re-hash everything. This patch simply adds VFS-level support for > > calling down to filesystems. > > This patch description starts out saying that IMA needs the file hash > without explaining why. Without that explanation, simply extracting > the file hash included in the file signature might sound plausible, > but kind of defeats the purpose of IMA. I'm not sure how it defeats the purpose - IMA wants to know the hash of a file so it can either log it or compare it against a signature, and it currently obtains this hash by reading the entire file at measurement time. If the filesystem later returns different data then IMA won't notice, which allows a malicious filesystem to bypass the measurements - there's no guarantee that we won't evict large parts of the copy of an executable that IMA read, and the filesystem can give us back a modified page when we page it back in. So IMA fundamentally relies on the filesystem to be trustworthy, and if we rely on the filesystem to be trustworthy then we should be able to rely on it to accurately store and provide the hash of a file.
