linux-kernel - Re: [RFC v2 7/7] modsig: build rules and scripts to generate keys and sign modules

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALLzPKbP_9jS2E=AG5gHsHYXEfxXh95j=UvwMfVA3OdgYF28eQ@mail.gmail.com>
Date:	Thu, 16 Aug 2012 23:12:25 +0300
From:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
To:	Josh Boyer <jwboyer@...il.com>
Cc:	zohar@...ux.vnet.ibm.com, jmorris@...ei.org, rusty@...tcorp.com.au,
	dhowells@...hat.com, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 7/7] modsig: build rules and scripts to generate keys and
 sign modules

On Thu, Aug 16, 2012 at 10:10 PM, Josh Boyer <jwboyer@...il.com> wrote:
> On Wed, Aug 15, 2012 at 2:43 PM, Dmitry Kasatkin
> <dmitry.kasatkin@...el.com> wrote:
>> This patch adds build rules and scripts to generate keys and sign modules.
>>
>> Two scripts has been added. genkey.sh is used to generate private and
>> public keys. ksign.sh is used to sign kernel modules. Both scripts
>> use only standard utilites from coreutils and additionally requires
>> openssl tool for RSA keys creation and signing.
>>
>> The patch modifies 'modules_install' target and adds two new targets to
>> the main kernel Makefile.
>>
>> 1. signed_modules_install
>> This target creates an ephemeral key pair, signs the kernel modules with
>> the private key, destroys the private key, and embeds the public key in
>> the kernel. (Thanks to Dave Hansen for the target name.)
>
> This requires CONFIG_INTEGRITY_MODULES to be enabled to actually do
> anything useful with the signed modules, correct?
>

Correct. It does not make sense to sign module if module support is disabled.
But there scripts/genkey.sh and ksign.sh which works without Makefiles.
So possible to generate keys and sign a module...

>>
>> 2. modules_install
>> When CONFIG_INTEGRITY_MODULES is enabled, this target uses an existing
>> private key to sign kernel modules.
>
> If the answer to the above question is yes, then why can't we stick
> with a single modules_install command for signing?  It would seem to me
> that calling signed_modules_install could use an existing key or
> generate an ephemeral key in the absence of one and install the signed
> modules, and modules_install would simply install unsigned modules.
>
> Or, alternatively, just make modules_install sign or not sign depending
> on whether CONFIG_INTEGRITY_MODULES is enabled.

This is what "make modules_install" does. It uses existing private key
and does not remove it after install.

>  I don't see why you
> would overload a target or create two different ones when both depend
> on that option.
>
> Could you explain the reasoning behind that a bit more?

The reason for "signed_modules_install" is to limit existence of private key.
Private key is generate just before install, modules installed and
signed, then key is destroyed.
So existence of private key is limited to "time make
signed_modules_install" execution time.

We had a debate about it, and strong message was that we might want to
do it like that...

With the "modules_install", it will not generate new private key
before install, but uses which is already in the directory..
And it will not remove the private key after install.

- Dmitry

>
> josh
--
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/