[PATCH v2 0/4] ima: unverifiable file signatures

[zohar@linux.vnet.ibm.com (Mimi Zohar)]

On Mon, 2018-02-26 at 20:08 -0600, Eric W. Biederman wrote:
> Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> 
> > For local filesystems, the kernel prevents files being executed from
> > being modified.  With IMA-measurement enabled, the kernel also emits
> > audit "time of measure, time of use" messages for files opened for
> > read, and subsequently opened for write.
> >
> > Files on fuse are initially measured, appraised, and audited.  Although
> > the file data can change dynamically any time, making re-measuring,
> > re-appraising, or re-auditing pointless, this patch set attempts to
> > differentiate between unprivileged non-init root and privileged
> > mounted fuse filesystems.
> >
> > This patch set addresses three different scenarios:
> > - Unprivileged non-init root mounted fuse filesystems are untrusted.
> >   Signature verification should always fail and re-measuring,
> >   re-appraising, re-auditing files makes no sense.
> >
> >   Always enabled.
> >
> > - For privileged mounted filesystems in a "secure" environment, with a
> >   correctly enforced security policy, which is willing to assume the
> >   inherent risk of specific fuse filesystems, it is reasonable to
> >   re-measure, re-appraise, and re-audit files.
> >
> >   Enabled by default to prevent breaking existing systems.
> >
> > - Privileged mounted filesystems unwilling to assume the risks and
> >   prefers to fail safe.
> >
> >   Enabled based on policy.
> 
> I really like the way the flags work in this patchset.
> 
> There is a lot of other nit-picking and bike-shedding I would like to
> do.  However those are details specific to IMA.  So my opion really
> doesn't count.
> 
> Those two flags set as you have them in the last patch make it possible
> to slightly alter details of when they get set, that are in the perview
> of filesystems without having too big a debate over them.
> 
> The changes I imagine most easily are:
> In fuse_fill_super:
> 	if (!fc->allow_other)
> 		sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER;

Right, as described, above, as the 2nd senario.

> 
> In sget_user_ns:
> 	if (sb->s_user_ns != &init_user_ns)
>         	sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER;

The filesystems would then only set SB_I_IMA_UNVERIFIABLE_SIGNATURE.

> 
> My biggest nitpick is I would be inclined to flip the sense of the
> unverifiable_sigs policy.  By default not trust and trust only if
> a special command line option was given.   But I realize this could
> run into backwards compatibility concerns.  And it is IMA specific so
> not really my call.

The boot command line policy option forces the system to fail safe.
Reversing the default to fail unverifiable_sigs and only allow them
based on policy, would not be a simple command line option, but would
require a per filesystem rule.

I agree with you, but as we're not breaking existing userspace, our
only option is to audit/log the concern, as suggested by Linus in
other threads. ?It would be nice if we could audit/log it once per
each mount.

> 
> But the important part is what winds up in the core of ima.  Baring
> typo's I think you have something we can all live with.
> 
> So double check yourself and let's start getting this merged.

Sure.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html