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

Mimi

> The only reasonable alternative I can come up with is to treat these
> mounts as though they don't support xattrs at all. In this case file
> appraisal would evaluate to INTEGRITY_UNKNOWN, and if enforcement were
> enabled executable and libraries would not be allowed on user ns mounts.
> 
> Thoughts?
> 
> Thanks,
> Seth