[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1361469979.29360.75.camel@falcor1>
Date: Thu, 21 Feb 2013 13:06:19 -0500
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: James Morris <jmorris@...ei.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>
Subject: Re: [GIT] Security subsystem updates for 3.9
On Thu, 2013-02-21 at 08:26 -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 6:03 AM, James Morris <jmorris@...ei.org> wrote:
> > This is basically a maintenance update for the TPM driver and EVM/IMA.
>
> Hmm. There were conflicts in lib/digsig.c and ima_main.c. The digsig
> one was pretty trivial, but I'd like people to take a look at the IMA
> one.
>
> And that's not because the conflict itself was all that complex - I'm
> pretty sure I resolved it correctly. But I do want to make sure that
> everybody agrees on the whole module integrity checking thing. I
> resolved it to be like the semantics in Mimi's commit a7f2a366f623,
> which means that for non-file modules, IMA does:
>
> Only fail the non-file module if
> (a) IMA_APPRAISE_MODULES was set
Almost, and enforcing file integrity is enabled. The merged result
should look like what's contained in
linux-integrity/next-upstreamed-patches:
int ima_module_check(struct file *file)
{
if (!file) {
if ((ima_appraise & IMA_APPRAISE_MODULES) &&
(ima_appraise & IMA_APPRAISE_ENFORCE)) {
#ifndef CONFIG_MODULE_SIG_FORCE
return -EACCES; /* INTEGRITY_UNKNOWN */
#endif
}
return 0;
}
return process_measurement(file, file->f_dentry->d_name.name,
MAY_EXEC, MODULE_CHECK);
}
thanks,
Mimi
> *and*
> (b) CONFIG_MODULE_SIG_FORCE is not set.
> If CONFIG_MODULE_SIG_FORCE it ignores IMA_APPRAISE_MODULES entirely,
> and the module signature checking overrides everything. And if
> IMA_APPRAISE_MODULES is not set, we say "whatever". So it makes sense,
> but I wanted people to just be aware of it and agree on it, since the
> security tree modified this part without apparently being aware of the
> changed semantics.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists