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]
Date:	Thu, 16 Aug 2012 15:10:01 -0400
From:	Josh Boyer <jwboyer@...il.com>
To:	Dmitry Kasatkin <dmitry.kasatkin@...el.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 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?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ