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

[Mimi Z. <zo...@li...>]

On Mo, 2016-08-01 at 15:38 -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.

Yeah, I remember.  Having one capability xattr sounded interesting.
Have the capability patches been upstreamed?   To label files in a
container, root in the namespace will need to be able to write an IMA
xattr.  Whether it is possible to use a single xattr, is yet to be
determined.

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

The EVM xattr is verified before it can be changed, to prevent making an
existing invalid hmac, valid.  If the namespace has the ability to
change any of the metadata included in the hmac, the EVM  hmac will need
to be updated with the file metadata, otherwise nobody will be able to
access the file.

> On read I am not certain what the right thing to do is, ignore the
> attribute or do what happens on validation failure.

> > 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.
> 
> One scenario where this is likely to come up, and the kind of scenario
> we are planning for is a filesystem on a usb stick is transported from
> one machine to another.  One the second system it is mounted directly
> (ideally) or through fuse running a copy of it's filesystem driver in
> userspace to guard against filesystem implementation bugs.
> 
> So if that filesystem has security.evm xattrs if it appears things will
> work very poorly.

It could work for files with EVM signatures, obviously not with an HMAC.

Mimi