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

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

On Mon, Aug 01, 2016 at 03:38:02PM -0500, Eric W. Biederman wrote:
> Mimi Zohar <zo...@li...> writes:
> 
> > On Mo, 2016-08-01 at 08:19 -0500, Seth Forshee wrote:
> >> I was taking a look at IMA and EVM in the context of allowing mounts in
> >> user namespaces from users with only capabilities in that namespace
> >> (i.e. no global capabilities). As a result of that I found just a
> >> handful of places where the size of an xattr or the values it contains
> >> lack sufficient validation to protect against malicious xattrs. The
> >> fixes for these are worthwhile on their own, so I'm sending them in the
> >> following patch.
> >> 
> >> More generally though I'd like to request some guidance on how IMA and
> >> EVM should handle xattrs in mounts from globally-unprivileged users. For
> >> context, the intended use case for this is allowing fuse mounts in user
> >> namespace containers, and possibly mounts with a limited set of other
> >> filesystems in the future. All that would actually be needed to mount
> >> though are private user and mount namespaces.
> >> 
> >> Based on what I see, I suspect that we can treat the user ns mounts like
> >> any other mount. I don't see that this would cause harm as long as the
> >> filesystem can't trigger bugs in the xattr parsing, and if the system is
> >> configured for IMA enforcment this policy should also be applied to
> >> these mounts.
> >
> > "security.evm" is written as a result of one of the protected security
> > xattrs being written.   From your question, I assume that in this use
> > case scenario there are two concerns:
> > - parsing improper security.evm xattrs
> > - updating the protected security xattrs, causing the EVM xattr to
> > "bless" the change.
> >
> > The first issue you're addressing with the patch.  As for the second
> > issue,  as long as root in the namespace can not write security.xattrs,
> > there shouldn't be a problem.
> 
> Assume that it is allowed that root in a namespace will be allowed to
> write security xattrs for a filesystem it has mounted.  Certainly for
> the capability xattr this makes sense.
> 
> If understand you correctly is that the key used to sign the HMAC in
> security.evm is machine local.  As such I expect the proper semantics
> here will be to not update the security.evm xattrs on write of a
> filesystem with s_user_ns != &init_user_ns.

I'm in agreement on this.

On the one hand, as long as the kernel is treating the xattrs from
s_user_ns != &init_user_ns with the proper caution (as it must) this
doesn't seem like a major problem.

The other side though is that if the user can turn around and trick the
system into mounting the filesystem in init_user_ns those xattrs are now
trusted. And that's a serious enough concern that we shouldn't write out
the security.evm xattrs in the first place.

Seth