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

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

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

Mimi