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

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

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.

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

Mimi