Messages in this thread |  | | Date | Mon, 12 Feb 2018 00:19:55 +1100 (AEDT) | From | James Morris <> | Subject | Re: [GIT PULL] Integrity: IMA FUSE fixes |
| |
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 <jmorris@namei.org> |  |