Re: [Linux-ima-user] [PATCH 0/1] EVM/IMA xattr hardening and unprivileged user ns mounts

[Seth F. <set...@ca...>]

On Tue, Sep 06, 2016 at 04:00:32PM -0400, Mimi Zohar wrote:
> On Thu, 2016-09-01 at 08:22 -0500, Seth Forshee wrote:
> 
> > I've been reading back through all of this, and I'm not sure any
> > conclusion was reached.
> 
> > For my part, I'm uneasy about writing out hmacs to mounts from a
> > non-root user. So I'll make a proposal - let's not read or write EVM or
> > IMA xattrs for filesystems from non-init user namespace, essentially
> > behaving as though they don't support xattrs. Something like the
> > (untested) patch below.
> 
> This really doesn't sound like the right long term solution.

I'm not proposing this for a long term solution. I just haven't seen
that anyone has a real use case in mind yet for using the integrity
subsystem with these mounts and that it might be better to wait and
decide exactly how it should behave until someone does. In the mean time
I'm just trying to ensure there won't be vulnerabilities to exploit.

> The kernel, as well as root in the namespace, should write the EVM and
> IMA security xattrs, as long as their usage is limited to the uid/gid
> associated with that user_ns namespace.

But keep in mind that the uid mapping doesn't get written out to disk.
If I create a file owned by uid 0 in my namespace (let's say that maps
to uid 1000 in init_user_ns) then uid 0 is what will be written to the
inode on disk.

Based on my understanding of what you said previously, this means that I
could create a file in my filesystem as root in my user ns and write out
a security.capability xattr, and the kernel would then write out an EVM
xattr with a valid signature. If I can then manage to get that file
mounted in init_user_ns the kernel will be owned by real root and the
kernel will see a valid signature for the capability xattr.

Granted, this scenario is problematic even without EVM, but it seems
like specifically the kind of thing someone might use EVM to protect
against.

Thanks,
Seth

> In terms of the USB stick scenario, instead of security.evm containing
> HMACs, they would need to be replaced with signatures, before using it
> on another system.  Refer to the ima-evm-utils package for writing out
> security.evm signatures.
> 
> Mimi
>