linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jessica Yu <jeyu@kernel.org>,
	David Howells <dhowells@redhat.com>,
	Seth Forshee <seth.forshee@canonical.com>,
	Justin Forbes <jforbes@redhat.com>,
	Matthew Garrett <mjg59@google.com>
Subject: Re: [PATCH] x86/ima: require signed kernel modules
Date: Mon, 04 Feb 2019 17:05:10 -0500	[thread overview]
Message-ID: <1549317910.4146.124.camel@linux.ibm.com> (raw)
In-Reply-To: <20190204203850.GP11489@garbanzo.do-not-panic.com>

On Mon, 2019-02-04 at 12:38 -0800, Luis Chamberlain wrote:
> On Thu, Jan 31, 2019 at 02:18:59PM -0500, Mimi Zohar wrote:
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 2ad1b5239910..70a9709d19eb 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -275,16 +275,23 @@ static void module_assert_mutex_or_preempt(void)
> >  
> >  static bool sig_enforce = IS_ENABLED(CONFIG_MODULE_SIG_FORCE);
> >  module_param(sig_enforce, bool_enable_only, 0644);
> > +static bool sig_required;
> >  
> >  /*
> >   * Export sig_enforce kernel cmdline parameter to allow other subsystems rely
> >   * on that instead of directly to CONFIG_MODULE_SIG_FORCE config.
> 
> But the docs were't updated.

Neither "CONFIG_MODULE_SIG_FORCE" nor "module.sig_enforce" has
changed.  Which docs are you referring to? 

> 
> >   */
> > -bool is_module_sig_enforced(void)
> > +bool is_module_sig_enforced_or_required(void)
> >  {
> > -	return sig_enforce;
> > +	return sig_enforce || sig_required;
> >  }
> > -EXPORT_SYMBOL(is_module_sig_enforced);
> > +EXPORT_SYMBOL(is_module_sig_enforced_or_required);
> 
> Meh, this is getting sloppy, the module signing infrastructure should
> just be LSM'ified now that we have stacked LSMs. That would
> compartamentaliz that code and make this much easier to read / understand
> and mantain.
> 
> Can you take a look at doing it that way instead?

This patch is about coordinating the existing methods of verifying
kernel module signatures.

> 
> > +
> > +void set_module_sig_required(void)
> > +{
> > +	sig_required = true;
> > +}
> > +EXPORT_SYMBOL(set_module_sig_required);
> 
> Since this is a *new* symbol, not yet used, and only used by IMA I'd
> prefer this to be EXPORT_SYMBOL_GPL().

Oops, this function shouldn't be exported.

> 
> >  /* Block module loading/unloading? */
> >  int modules_disabled = 0;
> > @@ -2789,7 +2796,7 @@ static int module_sig_check(struct load_info *info, int flags)
> >  	}
> >  
> >  	/* Not having a signature is only an error if we're strict. */
> > -	if (err == -ENOKEY && !is_module_sig_enforced())
> > +	if (err == -ENOKEY && !is_module_sig_enforced_or_required())
> 
> This is where I think a proper LSM hook would make sense. I think
> that these "questions" model for signing don't work well on the LSM
> hook model, perhaps just:
> 
> kernel_module_signed()
> 
> Suffices, therefore if not enforced or required its signed. If its
> enforced or required and really signed, then it signed.
> 
> >  		err = 0;
> >  
> >  	return err;
> > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > index 357edd140c09..bbaf87f688be 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -563,7 +563,7 @@ int ima_load_data(enum kernel_load_data_id id)
> >  		}
> >  		break;
> >  	case LOADING_MODULE:
> > -		sig_enforce = is_module_sig_enforced();
> > +		sig_enforce = is_module_sig_enforced_or_required();
> 
> Yet another user.
> 
> >  		if (ima_enforce && (!sig_enforce
> >  				    && (ima_appraise & IMA_APPRAISE_MODULES))) {
> > -- 
> > 2.7.5
> 
> Plus I think LSM'ifying module signing may help cleaning up some of the
> #ifdery and config options around module signing. I'm suggestin this now 
> as this has been on my mental TODO list for a while, and just not sure
> when we'd get to it, if not you, not sure when it'd get done.
> 
> Then, do we have proper unit tests for the mixture of options to ensure
> we can easily ensure we don't regress?
> 

There are already two methods  - appended signatures and IMA xattrs -
for validating kernel modules.

Kernel modules shouldn't be treated any differently than any other file.  Based on the IMA policy, the kernel module signature can be verified.  Also based on the IMA policy, the file hash added to the measurement list, and the file hash used to extend the TPM PCR.  Lastly, based on policy the file hash can be added to the audit log.

I don't see a need for an additional LSM just for verifying kernel module signatures.

Mimi


  reply	other threads:[~2019-02-04 22:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 19:18 [PATCH] ima: requiring signed kernel modules Mimi Zohar
2019-01-31 19:18 ` [PATCH] x86/ima: require " Mimi Zohar
2019-02-04 20:38   ` Luis Chamberlain
2019-02-04 22:05     ` Mimi Zohar [this message]
2019-02-04 22:30       ` Luis Chamberlain
2019-02-05 12:24         ` Mimi Zohar
2019-02-05 21:13           ` Luis Chamberlain
2019-02-05 23:13             ` Mimi Zohar
2019-02-05 15:18   ` Seth Forshee
2019-02-05 16:47     ` Mimi Zohar
2019-02-05 18:32       ` Seth Forshee
2019-02-05 18:52         ` Mimi Zohar
2019-02-08 19:21           ` Seth Forshee
2019-02-10 15:39             ` Mimi Zohar
2019-02-05 16:10   ` Nayna
2019-02-11 15:56   ` Jessica Yu
2019-02-11 16:19     ` 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=1549317910.4146.124.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=jeyu@kernel.org \
    --cc=jforbes@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mjg59@google.com \
    --cc=seth.forshee@canonical.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).