[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bogs492s.fsf@rustcorp.com.au>
Date: Thu, 27 Sep 2012 09:42:59 +0930
From: Rusty Russell <rusty@...tcorp.com.au>
To: David Howells <dhowells@...hat.com>
Cc: dhowells@...hat.com, herbert@...dor.hengli.com.au,
pjones@...hat.com, jwboyer@...hat.com,
linux-crypto@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, keyrings@...ux-nfs.org
Subject: Re: [GIT PULL] Asymmetric keys and module signing
David Howells <dhowells@...hat.com> writes:
> Rusty Russell <rusty@...tcorp.com.au> wrote:
>
>> We do a very simple search for a particular string appended to the module
>> (which is cache-hot and about to be SHA'd anyway). There's both a config
>> option and a boot parameter which control whether we accept (and taint) or
>> fail with unsigned modules.
>
> I've adjusted your patch description to this:
>
> We do a very simple search for a particular string appended to the module
> (which is cache-hot and about to be SHA'd anyway). There's both a config
> option and a boot parameter which control whether we accept or fail with
> unsigned modules and modules that are signed with an unknown key.
>
> If module signing is enabled, the kernel will be tainted if a module is
> accepted that is unsigned or has a signature for which we don't have the
> key.
>
> I think it's worth mentioning the policy for unknown keys and worth making
> clear under what circumstances we mean the kernel to be tainted.
Great! I checked your Kconfig help, too, which is states it clearly:
config MODULE_SIG_FORCE
bool "Require modules to be validly signed"
depends on MODULE_SIG
help
Reject unsigned modules or signed modules for which we don't have a
key. Without this, such modules will simply taint the kernel.
Which is really nice, since the kernel Kconfig help messages tend to
suck.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists