Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Kees Cook <keescook@chromium.org>]

On Tue, May 6, 2014 at 6:28 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> 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).

I'd like to be careful to avoid UEFI-specific thinking when dealing
with this. Module verification can also be done without signatures
(e.g. using the LSM to make sure they load from a read-only device).
Extending this so that a device with a known-good kernel environment
(be it UEFI Secure Boot, Chrome OS verified mode, or booting from a
CD-ROM) can extend itself with generated modules that the system owner
trusts in some additional way. (This is likely just adding a key for
module signing, but there's more to discuss: I don't want to have to
have ALL modules signed, for example, if I can already trust the
location where kernel-build-time modules are being loaded from, etc.)

-Kees

-- 
Kees Cook
Chrome OS Security