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:36:26PM -0400, Mimi Zohar wrote:
> 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.

Also wheter there are any problems with mounting a filesystem which
contains valid security.evm xattrs which fail verification with the key
in the kernel, or any other scenarios I might not have thought of.

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

We already have patches for the LSMs to make sure that they won't trust
security.* xattrs from user ns mounts, which have been merged into 4.8.
With that in place, would there still be a risk from letting namespace
root write those xattrs?

I'm not necessarily saying that we will let namespace root write those
xattrs, I'm just trying to understand if there's any risk beyond that of
letting the filesystem inject security policy via those xattrs.

> Any changes made offline/elsewhere, would
> result in the security.evm HMAC not verifying, causing a denial of
> service.  Unless of course the EVM HMAC key has somehow been
> leaked/exfiltrated from the kernel.

And by "denial of service" I take it you mean only with respect to that
filesystem? Or something else? When I read through the code I didn't get
the impression that HMAC verification failures would result in broader
problems.

Sorry to be asking fairly basic questions, but I'm not currently a user
of EVM so I want to confirm that my understanding of it is correct so
that we don't end up introducing any vulnerabilities.

Thanks,
Seth