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]>
On Mon, 2018-02-12 at 00:19 +1100, James Morris wrote:
> On Sat, 10 Feb 2018, Mimi Zohar wrote:
> > 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 problem is that fuse can provide whatever it wants, whenever it
wants. It could provide different pages for the initial file hash
calculation and then for usage.
If the file is first read into a buffer, like for the kernel_read_file_xxx() hooks, then the file data would be the same for the file calculation and usage, but for most of the IMA hooks, the file isn't first read into a buffer.
> 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?
That's all true, but I think the intent of these patches was to detect
malicious file change, where the fuse filesystem itself is malicious.
From the patch description:
It is useful in FUSE because the userspace FUSE process can change the
underlying files at any time without notifying the kernel. FUSE can be
mounted by unprivileged users either today with fusermount installed
with setuid, or soon with the upcoming patches to allow FUSE mounts in
a non-init user namespace. That makes the issue more visible than for
network filesystems where unprivileged users cannot mount.
For the example test provided, re-measuring the file works properly. I
had missed that if the fuse filesystem could provide different files,
at least in theory, it could also be able to provide different pages.
Mimi