On Tue, Nov 17, 2020 at 10:23:58AM -0800, Linus Torvalds wrote: > On Mon, Nov 16, 2020 at 10:35 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > > > We need to differentiate between signed files, which by definition are > > immutable, and those that are mutable. Appending to a mutable file, > > for example, would result in the file hash not being updated. > > Subsequent reads would fail. > > Why would that require any reading of the file at all AT WRITE TIME? > > Don't do it. Really. > > When opening the file write-only, you just invalidate the hash. It > doesn't matter anyway - you're only writing. > > Later on, when reading, only at that point does the hash matter, and > then you can do the verification. > > Although honestly, I don't even see the point. You know the hash won't > match, if you wrote to the file. I think the use case the IMA folks might be thinking about is where they want to validate the file at open time, *before* the userspace application starts writing to the file, since there might be some subtle attacks where Boris changes the first part of the file before Alice appends "I agree" to said file. Of course, Boris will be able to modify the file after Alice has modified it, so it's a bit of a moot point, but one could imagine a scenario where the file is modified while the system is not running (via an evil hotel maid) and then after Alice modifies the file, of *course* the hash will be invalid, so no one would notice. A sane application would have read the file to make sure it contained the proper contents before appending "I agree" to said file, so it's a bit of an esoteric point. The other case I could imagine is if the file is marked execute-only, without read access, and IMA wanted to be able to read the file to check the hash. But we already make an execption for allowing the file to be read during page faults, so that's probably less controversial. - Ted
