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

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

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

Thanks,
Seth