From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kees Cook <keescook@chromium.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching
Date: Tue, 06 May 2014 06:28:50 -0700 [thread overview]
Message-ID: <1399382930.2237.16.camel@dabdike.int.hansenpartnership.com> (raw)
In-Reply-To: <CAGXu5jKAcDrjUtrEdPjVY3dqYhX=UrZctH1-7=qRnGqaRcVcPw@mail.gmail.com>
On Tue, 2014-05-06 at 06:18 -0700, Kees Cook wrote:
> On Tue, May 6, 2014 at 12:05 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> > On Mon, 5 May 2014, Kees Cook wrote:
> >
> >> I'm very interested in this, especially as it may relate to security
> >> exploit mitigation work, both in the sense of being able to arbitrarily
> >> patch the kernel against flaws, and to defend against attackers being
> >> able to ... er ... arbitrarily patch the kernel... :)
> >
> > :) Well, for performing the patching, the attacker would either have to be
> > able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel
> > (criu-based solution). In either case, the system would be owned anyway
> > already, independently on any live patching mechanism.
>
> Right -- this is the current limitation with this kind of thing. I'd
> like to have both arbitrarily module loading blocked and the ability
> to load generated modules at a later time. I'm hoping there can be
> some discussion around providing a verification process for the newly
> created modules (e.g. signing the module on a separate machine that
> has private key material, etc).
This really belongs to the Secure Boot discussion not the live kernel
patching one ...
As you know, the problem has always been third party modules (what you
call "generated modules at a later time"). It's not really technical,
it's political: how do you arrive at the trusted key public key? The
distros didn't want to be in the business of signing modules (or keys).
The Red Hat kernel generation process even destroys the in-kernel key,
so it can't be used to sign them (although a validated RH key with trust
rooted somewhere in the secure boot system could). We've seen a lot of
"interesting" suggestions in this regard, like packaging the module up
into a windows like binary and getting Microsoft to sign it. At the end
of the day, I think we need a gpg like trust model: the distros all
assign public trust to vendor keys and the administrator has to decide
whether they want to install that vendor key based on the computed trust
from all the distros (so no signing, just assignment of trust).
James
next prev parent reply other threads:[~2014-05-06 13:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 19:42 Jiri Kosina
2014-05-02 21:17 ` James Bottomley
2014-05-04 8:34 ` Li Zefan
2014-05-05 14:00 ` Chris Mason
2014-05-05 21:58 ` Andy Lutomirski
2014-05-05 22:08 ` Jiri Kosina
2014-05-06 13:17 ` James Bottomley
2014-05-06 13:23 ` Pavel Emelyanov
2014-05-06 14:07 ` Chris Mason
2014-05-06 15:44 ` Pavel Emelyanov
2014-05-06 17:02 ` Chris Mason
2014-05-06 1:33 ` Kees Cook
2014-05-06 7:05 ` Jiri Kosina
2014-05-06 13:16 ` Dave Jones
2014-05-06 13:23 ` Jiri Kosina
2014-05-06 13:18 ` Kees Cook
2014-05-06 13:28 ` James Bottomley [this message]
2014-05-06 13:41 ` Kees Cook
2014-05-06 17:11 ` Mimi Zohar
2014-05-06 18:34 ` James Bottomley
2014-05-06 12:30 ` Masami Hiramatsu
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=1399382930.2237.16.camel@dabdike.int.hansenpartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=keescook@chromium.org \
--cc=ksummit-discuss@lists.linuxfoundation.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