Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Dave Young <dyoung@redhat.com>, David Howells <dhowells@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
	linux-efi@vger.kernel.org, gnomes@lxorguk.ukuu.org.uk,
	gregkh@linuxfoundation.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, Chun-Yi Lee <jlee@suse.com>,
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	matthew.garrett@nebula.com
Subject: Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set
Date: Fri, 07 Apr 2017 04:28:08 -0400	[thread overview]
Message-ID: <1491553688.4184.73.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170407074159.GB10737@dhcp-128-65.nay.redhat.com>

On Fri, 2017-04-07 at 15:41 +0800, Dave Young wrote:
> On 04/07/17 at 08:07am, David Howells wrote:
> > Dave Young <dyoung@redhat.com> wrote:
> > 
> > > > > > +	/* Don't permit images to be loaded into trusted kernels if we're not
> > > > > > +	 * going to verify the signature on them
> > > > > > +	 */
> > > > > > +	if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down())
> > > > > > +		return -EPERM;
> > > > > > +
> > > > > >  
> > > > 
> > > > IMA can be used to verify file signatures too, based on the LSM hooks
> > > > in  kernel_read_file_from_fd().  CONFIG_KEXEC_VERIFY_SIG should not be
> > > > required.
> > > 
> > > Mimi, I remember we talked somthing before about the two signature 
> > > verification. One can change IMA policy in initramfs userspace,
> > > also there are kernel cmdline param to disable IMA, so it can break the
> > > lockdown? Suppose kexec boot with ima disabled cmdline param and then
> > > kexec reboot again..
> > 
> > I guess I should lock down the parameter to disable IMA too.
> 
> That is one thing, user can change IMA policy in initramfs userspace,
> I'm not sure if IMA enforce the signed policy now, if no it will be also
> a problem.

I'm not sure how this relates to the question of whether IMA verifies
the kexec kernel image signature, as the test would not be based on a
Kconfig option, but on a runtime variable.

To answer your question, the rule for requiring the policy to be
signed is:  appraise func=POLICY_CHECK appraise_type=imasig

When the ability to append rules is Kconfig enabled, the builtin
policy requires the new policy or additional rules to be signed.
 Unfortunately, always requiring the policy to be signed, would have
broken userspace.

Mimi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2017-04-07  8:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
2017-04-05 20:15 ` [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down David Howells
2017-04-07  3:07   ` Dave Young
2017-04-05 20:15 ` [PATCH 08/24] Copy secure_boot flag in boot params across kexec reboot David Howells
2017-04-05 20:15 ` [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells
2017-04-07  3:05   ` Dave Young
2017-04-07  3:49     ` Mimi Zohar
2017-04-07  6:19       ` Dave Young
2017-04-07  7:07         ` David Howells
2017-04-07  7:41           ` Dave Young
2017-04-07  8:28             ` Mimi Zohar [this message]
2017-04-07  8:42               ` Dave Young
2017-04-07  7:45         ` Mimi Zohar
2017-04-07  8:01           ` Dave Young
2017-04-07  7:09       ` David Howells
2017-04-07  7:46         ` Mimi Zohar
2017-04-07  9:17           ` David Howells
2017-04-07 12:36             ` Mimi Zohar
2017-04-10 13:19               ` David Howells
2017-05-02 19:01                 ` 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=1491553688.4184.73.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jlee@suse.com \
    --cc=kexec@lists.infradead.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthew.garrett@nebula.com \
    --cc=mjg59@srcf.ucam.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox