On Sat, 10 Feb 2018, Mimi Zohar wrote: > > Which seems *worse* than what we do now, in that it wastes time and > > effort on re-creating those pointless measurements because it disables > > the caching of them. > > > > So honestly, the only sane thing seems to be to disable IMA on fuse, > > not to force it to do even _more_ pointless work. > > > > What am I missing? > > No, you're right. The file could change at any time, making the > measurement(s) and by extension signature verification meaningless.
Really? I thought the whole idea of IMA was that it only detects offline tampering and it specifically does not protect against runtime attacks. Any file could change after measurement on a compromised or misconfigured system. e.g. via direct write to the block device. > Custom policy rules could be defined to disable measurement, > appraisal, and audit for files on fuse. However, I don't think we > want to automatically disable measurement, even meaningless > measurements. Some indication needs to be included for remote > attestation, security analytics, or forensics. For systems with > policies that require file signatures even on fuse, the safest thing > would seem to be to fail the signature verification. I don't understand this -- if a file passes signature verification, it passes. If it was modified and still passes, the problem is elsewhere. I don't think the FUSE measurements are inherently useless, or more useless than any others, at least. You can misconfigure all kinds of things on a system which would undermine IMA, and I would count allowing unprivileged use of FUSE with critical files as such. The point of the patches, IIUC, was that FUSE had no useful way to notify IMA that a file had changed, so, always measure. IMA assumes that changes to a running system are made under the control of a correctly enforced security policy. If you're using FUSE and IMA, then you should understand the security implications of that. Or am I missing something? - James -- James Morris <[email protected]>
