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

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

On Wed, Sep 07, 2016 at 01:06:10PM -0400, Mimi Zohar wrote:
> On Wed, 2016-09-07 at 11:01 -0500, Seth Forshee wrote:
> > On Wed, Sep 07, 2016 at 11:20:19AM -0400, Mimi Zohar wrote:
> > > On Wed, 2016-09-07 at 07:27 -0500, Seth Forshee wrote:
> > > > On Tue, Sep 06, 2016 at 05:28:49PM -0400, Mimi Zohar wrote:
> > > > > On Tue, 2016-09-06 at 15:52 -0500, Seth Forshee wrote:
> > > > > > 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 main use case will be installing/updating packages within a
> > > > > container and writing the corresponding file signatures.  Unfortunately,
> > > > > we're not there yet.
> > > > 
> > > > Okay. If the distro is providing those signatures then I don't see a
> > > > problem with allowing them to be written. What concerns me is if there's
> > > > a scenario where the kernel would calculate and write out a signature or
> > > > hmac that would make the kernel trust the file in other contexts.
> > > 
> > > There's really no way of differentiating the source of the file
> > > signatures.  We either allow root in the namespace to write them or not.
> > 
> > I must be misunderstanding something then.
> 
> By file signature, I meant file data signature, which refers to IMA (not
> EVM).  

Okay. It does get a little confusing.

> > My impression was that for EVM we'd be dealing with some kind of keyed
> > signatures, not just hashes. In that case a user without the correct key
> > could write the EVM xattrs, then if the signature was correct the kernel
> > would permit access to the file, otherwise it would not.
> 
> Right, except the EVM signature is not portable, as it includes the
> inode in the signature.  Our work for including file signatures in
> packages is limited to the IMA file data signatures.  A new portable EVM
> format will be need for including EVM signatures in packages.
> 
> >  I.e. if the
> > user was installing distro packages which shipped with correct
> > signatures, the user could write those and the kernel would validate
> > them as correct. But if the user tried to write out their own files with
> > security xattrs they could not generate valid signatures, and the kernel
> > would deny access to those files.
> 
> > Is something about that incorrect?
> 
> That sounds right.  Userspace can write EVM signatures, using the
> ima-evm-utils package.  The asymmetric public key used for verifying the
> signature, would need to be loaded onto the EVM keyring.

Got it. Sounds like there currently wouldn't be any benefit to letting
ns-root write out EVM xattrs in that case. Of course we can't prevent
mounting a filesystem which already contains the xattrs, but we don't
have to make use of them.

> > > > So when s_user_ns != &init_user_ns it sounds like we could allow the
> > > > kernel to read and verify signatures and write out signatures provided
> > > > by userspace, but not calculate new/updated signatures for files. Does
> > > > that sound reasonable?
> > > 
> > > Not really.  At least initially, perhaps we should be differentiating
> > > between EVM and IMA xattrs, allowing only IMA xattrs to be read/written
> > > and returning EOPNOTSUPP, as you suggested, for EVM.  Having just IMA
> > > xattrs, without EVM xattrs, would then work in the namespace, but not
> > > outside of it (assuming EVM is enabled).
> > 
> > That's okay with me assuming it doesn't weaken security for systems with
> > EVM enabled. We're already effectively ignoring LSM security xattrs and
> > scoping capability xattrs to s_user_ns, so I think we should be okay.
> 
> The worst, which would be bad, is preventing access to a file, but it
> wouldn't make an invalid EVM signature/hmac valid.

Yeah, I've been taking another look at the code today and saw that was
the case. The only time I see the kernel writing out a new signature is
for IMA xattrs which are only digests and not signatures. So that seems
okay, and some of my concerns were unfounded.

I'll work up a patch then to deny reading and writing of EVM xattrs when
s_user_ns != &init_user_ns.

Thanks,
Seth