From: Vivek Goyal <vgoyal@redhat.com>
To: Matthew Garrett <mjg@redhat.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Khalid Aziz <khalid@gonehiking.org>,
kexec@lists.infradead.org, horms@verge.net.au,
Dave Young <dyoung@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Dmitry Kasatkin <dmitry.kasatkin@intel.com>,
Roberto Sassu <roberto.sassu@polito.it>,
Kees Cook <keescook@chromium.org>
Subject: Re: Kdump with signed images
Date: Fri, 26 Oct 2012 13:06:09 -0400 [thread overview]
Message-ID: <20121026170609.GB24687@redhat.com> (raw)
In-Reply-To: <20121026023916.GA16762@srcf.ucam.org>
On Fri, Oct 26, 2012 at 03:39:16AM +0100, Matthew Garrett wrote:
> On Thu, Oct 25, 2012 at 09:15:58PM -0400, Mimi Zohar wrote:
>
> > On a running system, the package installer, after verifying the package
> > integrity, would install each file with the associated 'security.ima'
> > extended attribute. The 'security.evm' digital signature would be
> > installed with an HMAC, calculated using a system unique key.
>
> The idea isn't to prevent /sbin/kexec from being modified after
> installation - it's to prevent it from being possible to install a
> system that has a modified /sbin/kexec. Leaving any part of this up to
> the package installer means that it doesn't solve the problem we're
> trying to solve here. It must be impossible for the kernel to launch any
> /sbin/kexec that hasn't been signed by a trusted key that's been built
> into the kernel, and it must be impossible for anything other than
> /sbin/kexec to make the kexec system call.
I am kind of lost now so just trying to summarize whatever I have
learned so far from this thread.
- So say we can sign /sbin/kexec at build time and distros can do that.
- Verify the signature at exec time using kernel keyring and if
verification happens successfully, say process gains extra capability.
- Use this new capability to determine whether kexec_load() will be
successful or not.
Even if we can do all this, it still has the issue of being able to
stop the process in user space and replace the code at run time
and be able to launch unsigned kernel.
So until and unless we have a good solution to verify application's
integrity/authneticity at the time of kexec_load() system call we
still have the problem. And I don't think we have come up with a
solution for that yet (until and unless I missed something).
Thanks
Vivek
next prev parent reply other threads:[~2012-10-26 17:06 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1350588121.30243.7.camel@rhapsody>
[not found] ` <20121018193831.GD18147@redhat.com>
[not found] ` <874nlrv2ni.fsf@xmission.com>
[not found] ` <20121019020630.GA27052@redhat.com>
[not found] ` <877gqnnnf0.fsf@xmission.com>
[not found] ` <20121019143112.GB27052@redhat.com>
[not found] ` <871ugqb4gj.fsf@xmission.com>
[not found] ` <20121023131854.GA16496@redhat.com>
[not found] ` <20121023145920.GD16496@redhat.com>
[not found] ` <87fw552mb4.fsf_-_@xmission.com>
2012-10-24 17:36 ` Kdump with signed images Vivek Goyal
2012-10-25 6:10 ` Mimi Zohar
2012-10-25 14:10 ` Vivek Goyal
2012-10-25 18:40 ` Mimi Zohar
2012-10-25 18:55 ` Vivek Goyal
2012-10-26 1:15 ` Mimi Zohar
2012-10-26 2:39 ` Matthew Garrett
2012-10-26 3:30 ` Eric W. Biederman
2012-10-26 17:06 ` Vivek Goyal [this message]
2012-10-26 18:37 ` Mimi Zohar
2012-11-01 13:10 ` Vivek Goyal
2012-11-01 13:53 ` Vivek Goyal
2012-11-01 14:29 ` Mimi Zohar
2012-11-01 14:43 ` Vivek Goyal
2012-11-01 14:52 ` Matthew Garrett
2012-11-02 13:23 ` Vivek Goyal
2012-11-02 14:29 ` Balbir Singh
2012-11-02 14:36 ` Vivek Goyal
2012-11-03 3:02 ` Balbir Singh
2012-11-02 21:34 ` H. Peter Anvin
2012-11-02 21:32 ` Eric W. Biederman
2012-11-05 18:03 ` Vivek Goyal
2012-11-05 19:44 ` Eric W. Biederman
2012-11-05 20:42 ` Vivek Goyal
2012-11-05 23:01 ` H. Peter Anvin
2012-11-06 19:34 ` Vivek Goyal
2012-11-06 23:51 ` Eric W. Biederman
2012-11-08 19:40 ` Vivek Goyal
2012-11-08 19:45 ` Vivek Goyal
2012-11-08 21:03 ` Eric W. Biederman
2012-11-09 14:39 ` Vivek Goyal
2012-11-15 5:09 ` Eric W. Biederman
2012-11-15 12:56 ` Mimi Zohar
2012-11-08 20:46 ` Mimi Zohar
2012-11-01 14:51 ` Vivek Goyal
2012-11-01 14:57 ` Matthew Garrett
2012-11-01 15:10 ` Khalid Aziz
2012-11-01 16:23 ` Matthew Garrett
2012-11-02 16:57 ` Khalid Aziz
2012-10-26 17:59 ` Mimi Zohar
2012-10-26 18:19 ` Matthew Garrett
2012-10-26 18:25 ` Mimi Zohar
[not found] ` <20121023154123.GA30730@srcf.ucam.org>
[not found] ` <87d309xhmc.fsf_-_@xmission.com>
2012-10-24 17:19 ` [RFC] " Vivek Goyal
2012-10-25 5:43 ` Mimi Zohar
2012-10-25 6:44 ` Kees Cook
2012-10-25 7:01 ` Mimi Zohar
2012-10-25 13:54 ` Vivek Goyal
2012-10-25 19:06 ` Mimi Zohar
2012-10-25 15:39 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Vivek Goyal
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=20121026170609.GB24687@redhat.com \
--to=vgoyal@redhat.com \
--cc=dmitry.kasatkin@intel.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=khalid@gonehiking.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=roberto.sassu@polito.it \
--cc=zohar@linux.vnet.ibm.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).