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] [day] [month] [year] [list]
Date:	Sat, 18 Jul 2015 23:56:53 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	linux-kernel@...r.kernel.org
CC:	linux-kbuild@...r.kernel.org, Michal Marek <mmarek@...e.cz>,
	David Howells <dhowells@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] modsign: provide option to automatically delete the key
 after modules were installed

Hello,

besides that calling rm on Linux is just snake oil, the patch below 
still automatically hides the key used to sign modules and offers a 
statistically good chance that the key sometimes might physically 
disappear from the storage used to compile a kernel. So many people 
still might consider it useful. As mentioned below, at least one well 
known person seems to might find it useful too.

Should I rewrite the commit message (e.g. to nothing as the subject 
already describes it perfectly) or is the chance to get such stuff from 
someone outside the holy circles included already zero?

Sorry for asking (that way), but I'm curious if there is really zero 
interest in it.

Regards,

Alexander Holler

Am 23.01.2015 um 02:20 schrieb Alexander Holler:
> I usually throw away (delete) the key used to sign modules after having
> called make -jN (b)zImage modules && make -jN modules_install. Because I've
> got bored to always have to type rm signing_key.* afterwards, I've build
> this patch some time ago.
> As I'm not eager anymore to publish kernel patches, it rested in my private
> chest of patches until I've seen the keynote of Linux.conf.au 2015. It made
> me aware that this patch might have a chance to become included. ;)
>
> Signed-off-by: Alexander Holler <holler@...oftware.de>
> ---
>   Makefile     |  7 +++++++
>   init/Kconfig | 12 ++++++++++++
>   2 files changed, 19 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index fb93350..95e07ca 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1129,6 +1129,13 @@ _modinst_:
>   	@cp -f $(objtree)/modules.order $(MODLIB)/
>   	@cp -f $(objtree)/modules.builtin $(MODLIB)/
>   	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
> +ifeq ($(CONFIG_MODULE_SIG_THROW_AWAY), y)
> +	@echo "###"
> +	@echo "### Deleting key used to sign modules."
> +	@echo "###"
> +	@rm ./signing_key.priv
> +	@rm ./signing_key.x509
> +endif
>
>   # This depmod is only for convenience to give the initial
>   # boot a modules.dep even before / is mounted read-write.  However the
> diff --git a/init/Kconfig b/init/Kconfig
> index 9afb971..f29304e 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1884,6 +1884,18 @@ config MODULE_SIG_ALL
>   	  Sign all modules during make modules_install. Without this option,
>   	  modules must be signed manually, using the scripts/sign-file tool.
>
> +config MODULE_SIG_THROW_AWAY
> +	bool "Automatically delete the key after modules were installed"
> +	default n
> +	depends on MODULE_SIG_ALL
> +	help
> +	  Delete the key used to sign modules after modules were installed.
> +	  Be aware of the consequences. The downside is that you  won't be
> +	  able to build any module for a (maybe running) kernel, but will
> +	  have to rebuild the kernel and all modules in order to add or modify
> +	  a module. The upside is that you don't have to secure the key in
> +	  order to keep a running kernel safe from unwanted modules.
> +
>   comment "Do not forget to sign required modules with scripts/sign-file"
>   	depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL
>
>

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