linux-kernel - Re: [GIT PULL] Integrity: IMA FUSE fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1518358046.5491.187.camel@linux.vnet.ibm.com>
Date:   Sun, 11 Feb 2018 09:07:26 -0500
From:   Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:     James Morris <jmorris@...ei.org>
Cc:     linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [GIT PULL] Integrity: IMA FUSE fixes

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