From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: James Morris <jmorris@namei.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>
Subject: Re: [GIT] Security subsystem updates for 3.9
Date: Thu, 21 Feb 2013 13:06:19 -0500 [thread overview]
Message-ID: <1361469979.29360.75.camel@falcor1> (raw)
In-Reply-To: <CA+55aFzkBA6bdLe73PKBaQNfV1m-JqSddF24-F-s1rX3oRE2Lg@mail.gmail.com>
On Thu, 2013-02-21 at 08:26 -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 6:03 AM, James Morris <jmorris@namei.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.
next prev parent reply other threads:[~2013-02-21 18:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-21 14:03 [GIT] Security subsystem updates for 3.9 James Morris
2013-02-21 16:26 ` Linus Torvalds
2013-02-21 18:06 ` Mimi Zohar [this message]
2013-02-21 18:21 ` Linus Torvalds
2013-02-21 19:03 ` Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1361469979.29360.75.camel@falcor1 \
--to=zohar@linux.vnet.ibm.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.