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:	Fri, 23 Jan 2015 13:34:42 +0100
From:	Alexander Holler <holler@...oftware.de>
To:	Michal Marek <mmarek@...e.cz>, linux-kernel@...r.kernel.org
CC:	linux-kbuild@...r.kernel.org, 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

Am 23.01.2015 um 12:54 schrieb Alexander Holler:
> Am 23.01.2015 um 12:43 schrieb Alexander Holler:
>> Am 23.01.2015 um 11:55 schrieb Michal Marek:
>
>>> The .x509 file contains a certificate signed by the private key, but not
>>> the private key. With some scripting, it can be used to verify the
>>> module signatures.
>>
>>
>> Assuming that doesn't change (hopefully), I'll send v2 in a few minutes
>> (it just compiles in order to test it). Thanks for assuring me that
>> .x509 does not and will not contain the private key.
>
> I'm happy I did that. Just deleting the private key currently doesn't
> work. A subsequent make fails:
>
> -----------------------------
> (...)
>    INSTALL arch/x86/crypto/aesni-intel.ko
> Can't read private key
> (...)
> -----------------------------
>
> Maybe that's the reason I've always deleted both files, can't remember.
>
> I will see if I find the time and passion to change the Makefile in
> order to fix that. So you might either use my existing patch or wait if
> I will send a new one.

Having had a look at the Makefile, I don't think I will change that. The 
reasons are:

1. I have no idea about how distro maintainers do handle their private 
and public keys used to sign modules.

2. There might be legitimate reasons to build the kernel using only the 
public key and not regenerating it because the private key doesn't exist.

3. I don't see any real reason not to delete the public key too if this 
new option is enabled. For me it's enough if the kernel is able to 
verify the modules with the embedded public key. For other usage 
scenarios one just should not use the new option.

4. With some scripting it should be possible to extract the public key 
out of an existing binary kernel. So there is no real need to change the 
already complicated build process which might make it even more complicated.

That means I'm still happy with the patch. So feel free to ignore or 
apply it.

Regards,

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