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

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

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.

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"?
Ok, hard coding this rule probably is not a good idea. ?For those
wanting to take this liability on their systems, we can make this
configurable, like for privileged fuse mounts. ?Unlike for privileged
fuse mounts, the builtin policies, I think, should be fail safe and
include the "fail" rule for unprivileged fuse mounts.

quoted

The remaining patches are policy based.

quoted

Good thing we can partially work around that by intercepting real
mount calls with Tycho's new patchset :)

Can you provide a little more details?

It would allow a container runtime to intercept mount(2) and perform
a real mount on the user's behalf.  Assuming the runtime is privileged,
of course, otherwise it would intercept and do a fuse mount which is
no help here :)

https://lkml.org/lkml/2018/2/4/28

thanks!

Mimi

--
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