[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1361473420.29360.97.camel@falcor1>
Date: Thu, 21 Feb 2013 14:03:40 -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 10:21 -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 10:06 AM, Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
> >
> > 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;
>
> Ugh. The placement of that #ifndef is just horrible, please don't do
> that. Just add it around the whole if-statement rather than around
> just the return. Not because the compiler can't optimize away the
> tests, but because it's much more obvious to a *human* what the ifndef
> actually does.
Having the 'ifndef' is ugly. Thanks for the suggestion on making it
less ugly.
> Anyway, I don't have the IMA_APPRAISE_ENFORCE bit checking, it wasn't
> obvious from the conflict, so somebody will need to add that.
Commit "750943a ima: remove enforce checking duplication" moved the test
to process_measurement().
Because commit "a7f2a36 ima: fallback to MODULE_SIG_ENFORCE for existing
kernel module syscall" never went into linux-security/next, subsequent
patches resulted in this merge conflict.
I'll post an additional patch.
thanks,
Mimi
--
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