[RFC PATCH 2/4] ima: fail signature verification on unprivileged & untrusted filesystems

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

On Wed, 2018-02-14 at 09:16 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

On Wed, 2018-02-14 at 08:49 -0600, Serge E. Hallyn wrote:

quoted

Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):

quoted

Files on untrusted filesystems, such as fuse, can change at any time,
making the measurement(s) and by extension signature verification
meaningless.

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.

This patch always fails the file signature verification on unprivileged
and untrusted filesystems.  To also fail file signature verification on

Why only untrusted?  Fuse could cause the same issue if it just
messes up when mounted from init userns right?

Right, whether it is an unprivileged mount or not, fuse can return
whatever it wants, whenever it wants. ?IMA can calculate the file hash
based based on what it reads, but fuse can return whatever it wants on
subsequent reads.

Ok but your patch seems to let privileged fuse mounts slide?  (see below)

Unprivileged fuse mounts hasn't been upstreamed yet, so we wouldn't be
breaking existing userspace.

I don't think I'm being clear.

In your patch it looks like you mark unprivileged FUSE mounts as
INTEGRITY_FAIL.  I agree you should do that.  But you skip the
FS_UNTRUSTED check for privileged FUSE mounts.  I'm asking why
that's ok.

quoted

quoted

Refer to the discussion with Linus -?http://kernsec.org/pipermail/linu
x-security-module-archive/2018-February/005200.html

quoted

quoted

privileged, untrusted filesystems requires a custom policy.

(I'm not saying you shouldn't do this, but) does this mean that
a container whose rootfs is fuse-mounted by the unprivileged user
cannot possibly use IMA?

How would you suggest to differentiate between your unprivileged fuse
mounts from unintended, unintended malicious ones?

I wouldn't.

What happened to the requirement that systems should be "fail-safe"?

My point was - I was asking whether there was any way to have IMA be
meaningful with such containers, not saying I had any ideas, and
certainly not saying that just because you can't detect it means you
should allow it in all cases.  It's too bad that it has this effect,
but I agree with your patch.

I only didn't ack it because you're skipping the check for privileged
mounts which seems wrong.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html