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: <1345147963.3402.37.camel@falcor.watson.ibm.com>
Date:	Thu, 16 Aug 2012 16:12:43 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Josh Boyer <jwboyer@...il.com>
Cc:	Dmitry Kasatkin <dmitry.kasatkin@...el.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, 2012-08-16 at 15:10 -0400, Josh Boyer 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?
> 
> >
> > 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.  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?

If the key exists during the build, there is no need for the additional
'make bzImage'.  I'll update the patch description based on the
following explaination taken from the cover letter:

For the developer, these patches create an ephemeral key during module
install, in order to limit the duration of the private key's existence.
Unfortunately, this necessitates embedding the public key in the kernel,
after the kernel has already been built.  A new make target called
'signed_modules_install', creates the keypair, signs the modules,
removes the private key, and then, for now, recompiles the kernel using
'make bzImage'.  For the developer, instead of doing 'make
modules_install', the new build process would be 'make', followed by
'make signed_modules_install' and 'make install'.

thanks,

Mimi

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