* [GIT PULL] Crypto keys and module signing
@ 2011-12-07 14:47 David Howells
2011-12-09 4:05 ` James Morris
2011-12-10 11:42 ` Arkadiusz Miśkiewicz
0 siblings, 2 replies; 17+ messages in thread
From: David Howells @ 2011-12-07 14:47 UTC (permalink / raw)
To: jmorris, linux-security-module
Cc: dhowells, keyrings, linux-kernel, dmitry.kasatkin, zohar, arjan,
alan
Hi James,
Could you pull my module signing code into the security tree? The patches can
be viewed here:
http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/devel
The only significant difference between the version #3 patch posting I made
and the current code is that I've discarded the DSA algorithm and the
references to it.
I haven't included the MPI lib commits from Dmitry as they should be the same
as reside in your tree already.
David
---
The following changes since commit 7e8dec918ef8e0f68b4937c3c50fa57002077a4d:
crypto: GnuPG based MPI lib - additional sources (part 4) (2011-11-09 11:47:26 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-modsign.git devel
David Howells (20):
MPILIB: Export some more symbols
MPILIB: Add a missing ENOMEM check
KEYS: Permit key_serial() to be called with a const key pointer
KEYS: Move the key config into security/keys/Kconfig
KEYS: Announce key type (un)registration
KEYS: Reorganise keys Makefile
KEYS: Create a key type that can be used for general cryptographic operations
KEYS: Add signature verification facility
KEYS: Asymmetric public-key algorithm crypto key subtype
KEYS: RSA signature verification algorithm
PGPLIB: PGP definitions (RFC 4880)
PGPLIB: Basic packet parser
PGPLIB: Signature parser
KEYS: PGP data parser
KEYS: PGP-based public key signature verification
KEYS: PGP format signature parser
KEYS: Provide a function to load keys from a PGP keyring blob
MODSIGN: Add indications of module ELF types
MODSIGN: Module ELF verifier
MODSIGN: Apply signature checking to modules on module load
.gitignore | 15 +
Documentation/module-signing.txt | 186 +++++++
Documentation/security/keys-crypto.txt | 302 +++++++++++
Makefile | 1 +
arch/alpha/include/asm/module.h | 3 +
arch/arm/include/asm/module.h | 5 +
arch/cris/include/asm/module.h | 5 +
arch/h8300/include/asm/module.h | 5 +
arch/ia64/include/asm/module.h | 5 +
arch/m32r/include/asm/module.h | 5 +
arch/m68k/include/asm/module.h | 5 +
arch/mips/include/asm/module.h | 12 +-
arch/parisc/include/asm/module.h | 8 +
arch/powerpc/include/asm/module.h | 10 +
arch/s390/include/asm/module.h | 3 +
include/asm-generic/module.h | 10 +
include/keys/crypto-subtype.h | 77 +++
include/keys/crypto-type.h | 37 ++
include/linux/elfnote.h | 4 +
include/linux/key.h | 2 +-
include/linux/modsign.h | 27 +
include/linux/module.h | 3 +
include/linux/pgp.h | 255 +++++++++
init/Kconfig | 65 +++
kernel/Makefile | 4 +
kernel/modsign-pubkey.c | 44 ++
kernel/module-verify-elf.c | 344 ++++++++++++
kernel/module-verify-sig.c | 526 ++++++++++++++++++
kernel/module-verify.c | 44 ++
kernel/module-verify.h | 68 +++
kernel/module.c | 25 +-
lib/mpi/mpi-cmp.c | 2 +
lib/mpi/mpi-div.c | 1 +
lib/mpi/mpi-inv.c | 1 +
lib/mpi/mpi-mpow.c | 1 +
lib/mpi/mpi-mul.c | 1 +
lib/mpi/mpicoder.c | 2 +
net/dns_resolver/dns_key.c | 5 -
scripts/Makefile.modpost | 85 +++-
scripts/mod/.gitignore | 1 +
scripts/mod/Makefile | 2 +-
scripts/mod/mod-extract.c | 913 ++++++++++++++++++++++++++++++++
scripts/mod/modsign-note.sh | 16 +
security/Kconfig | 68 +---
security/keys/Kconfig | 121 +++++
security/keys/Makefile | 25 +-
security/keys/crypto_keys.h | 28 +
security/keys/crypto_rsa.c | 282 ++++++++++
security/keys/crypto_type.c | 228 ++++++++
security/keys/crypto_verify.c | 111 ++++
security/keys/key.c | 3 +
security/keys/pgp_key_parser.c | 344 ++++++++++++
security/keys/pgp_library.c | 531 +++++++++++++++++++
security/keys/pgp_parser.h | 35 ++
security/keys/pgp_preload.c | 90 ++++
security/keys/pgp_pubkey_sig.c | 323 +++++++++++
security/keys/pgp_sig_parser.c | 104 ++++
security/keys/public_key.c | 55 ++
security/keys/public_key.h | 108 ++++
59 files changed, 5506 insertions(+), 85 deletions(-)
create mode 100644 Documentation/module-signing.txt
create mode 100644 Documentation/security/keys-crypto.txt
create mode 100644 include/keys/crypto-subtype.h
create mode 100644 include/keys/crypto-type.h
create mode 100644 include/linux/modsign.h
create mode 100644 include/linux/pgp.h
create mode 100644 kernel/modsign-pubkey.c
create mode 100644 kernel/module-verify-elf.c
create mode 100644 kernel/module-verify-sig.c
create mode 100644 kernel/module-verify.c
create mode 100644 kernel/module-verify.h
create mode 100644 scripts/mod/mod-extract.c
create mode 100644 scripts/mod/modsign-note.sh
create mode 100644 security/keys/Kconfig
create mode 100644 security/keys/crypto_keys.h
create mode 100644 security/keys/crypto_rsa.c
create mode 100644 security/keys/crypto_type.c
create mode 100644 security/keys/crypto_verify.c
create mode 100644 security/keys/pgp_key_parser.c
create mode 100644 security/keys/pgp_library.c
create mode 100644 security/keys/pgp_parser.h
create mode 100644 security/keys/pgp_preload.c
create mode 100644 security/keys/pgp_pubkey_sig.c
create mode 100644 security/keys/pgp_sig_parser.c
create mode 100644 security/keys/public_key.c
create mode 100644 security/keys/public_key.h
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [GIT PULL] Crypto keys and module signing 2011-12-07 14:47 [GIT PULL] Crypto keys and module signing David Howells @ 2011-12-09 4:05 ` James Morris 2011-12-09 9:17 ` David Howells 2011-12-10 11:42 ` Arkadiusz Miśkiewicz 1 sibling, 1 reply; 17+ messages in thread From: James Morris @ 2011-12-09 4:05 UTC (permalink / raw) To: David Howells Cc: linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, arjan, alan On Wed, 7 Dec 2011, David Howells wrote: > > Hi James, > > Could you pull my module signing code into the security tree? The patches can > be viewed here: I'm getting this build error: make[1]: *** No rule to make target `kernel.pub', needed by `kernel/modsign-pubkey.o'. Stop. > > http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/devel > > The only significant difference between the version #3 patch posting I made > and the current code is that I've discarded the DSA algorithm and the > references to it. > > I haven't included the MPI lib commits from Dmitry as they should be the same > as reside in your tree already. > > David > --- > The following changes since commit 7e8dec918ef8e0f68b4937c3c50fa57002077a4d: > > crypto: GnuPG based MPI lib - additional sources (part 4) (2011-11-09 11:47:26 +0200) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-modsign.git devel > > David Howells (20): > MPILIB: Export some more symbols > MPILIB: Add a missing ENOMEM check > KEYS: Permit key_serial() to be called with a const key pointer > KEYS: Move the key config into security/keys/Kconfig > KEYS: Announce key type (un)registration > KEYS: Reorganise keys Makefile > KEYS: Create a key type that can be used for general cryptographic operations > KEYS: Add signature verification facility > KEYS: Asymmetric public-key algorithm crypto key subtype > KEYS: RSA signature verification algorithm > PGPLIB: PGP definitions (RFC 4880) > PGPLIB: Basic packet parser > PGPLIB: Signature parser > KEYS: PGP data parser > KEYS: PGP-based public key signature verification > KEYS: PGP format signature parser > KEYS: Provide a function to load keys from a PGP keyring blob > MODSIGN: Add indications of module ELF types > MODSIGN: Module ELF verifier > MODSIGN: Apply signature checking to modules on module load > > .gitignore | 15 + > Documentation/module-signing.txt | 186 +++++++ > Documentation/security/keys-crypto.txt | 302 +++++++++++ > Makefile | 1 + > arch/alpha/include/asm/module.h | 3 + > arch/arm/include/asm/module.h | 5 + > arch/cris/include/asm/module.h | 5 + > arch/h8300/include/asm/module.h | 5 + > arch/ia64/include/asm/module.h | 5 + > arch/m32r/include/asm/module.h | 5 + > arch/m68k/include/asm/module.h | 5 + > arch/mips/include/asm/module.h | 12 +- > arch/parisc/include/asm/module.h | 8 + > arch/powerpc/include/asm/module.h | 10 + > arch/s390/include/asm/module.h | 3 + > include/asm-generic/module.h | 10 + > include/keys/crypto-subtype.h | 77 +++ > include/keys/crypto-type.h | 37 ++ > include/linux/elfnote.h | 4 + > include/linux/key.h | 2 +- > include/linux/modsign.h | 27 + > include/linux/module.h | 3 + > include/linux/pgp.h | 255 +++++++++ > init/Kconfig | 65 +++ > kernel/Makefile | 4 + > kernel/modsign-pubkey.c | 44 ++ > kernel/module-verify-elf.c | 344 ++++++++++++ > kernel/module-verify-sig.c | 526 ++++++++++++++++++ > kernel/module-verify.c | 44 ++ > kernel/module-verify.h | 68 +++ > kernel/module.c | 25 +- > lib/mpi/mpi-cmp.c | 2 + > lib/mpi/mpi-div.c | 1 + > lib/mpi/mpi-inv.c | 1 + > lib/mpi/mpi-mpow.c | 1 + > lib/mpi/mpi-mul.c | 1 + > lib/mpi/mpicoder.c | 2 + > net/dns_resolver/dns_key.c | 5 - > scripts/Makefile.modpost | 85 +++- > scripts/mod/.gitignore | 1 + > scripts/mod/Makefile | 2 +- > scripts/mod/mod-extract.c | 913 ++++++++++++++++++++++++++++++++ > scripts/mod/modsign-note.sh | 16 + > security/Kconfig | 68 +--- > security/keys/Kconfig | 121 +++++ > security/keys/Makefile | 25 +- > security/keys/crypto_keys.h | 28 + > security/keys/crypto_rsa.c | 282 ++++++++++ > security/keys/crypto_type.c | 228 ++++++++ > security/keys/crypto_verify.c | 111 ++++ > security/keys/key.c | 3 + > security/keys/pgp_key_parser.c | 344 ++++++++++++ > security/keys/pgp_library.c | 531 +++++++++++++++++++ > security/keys/pgp_parser.h | 35 ++ > security/keys/pgp_preload.c | 90 ++++ > security/keys/pgp_pubkey_sig.c | 323 +++++++++++ > security/keys/pgp_sig_parser.c | 104 ++++ > security/keys/public_key.c | 55 ++ > security/keys/public_key.h | 108 ++++ > 59 files changed, 5506 insertions(+), 85 deletions(-) > create mode 100644 Documentation/module-signing.txt > create mode 100644 Documentation/security/keys-crypto.txt > create mode 100644 include/keys/crypto-subtype.h > create mode 100644 include/keys/crypto-type.h > create mode 100644 include/linux/modsign.h > create mode 100644 include/linux/pgp.h > create mode 100644 kernel/modsign-pubkey.c > create mode 100644 kernel/module-verify-elf.c > create mode 100644 kernel/module-verify-sig.c > create mode 100644 kernel/module-verify.c > create mode 100644 kernel/module-verify.h > create mode 100644 scripts/mod/mod-extract.c > create mode 100644 scripts/mod/modsign-note.sh > create mode 100644 security/keys/Kconfig > create mode 100644 security/keys/crypto_keys.h > create mode 100644 security/keys/crypto_rsa.c > create mode 100644 security/keys/crypto_type.c > create mode 100644 security/keys/crypto_verify.c > create mode 100644 security/keys/pgp_key_parser.c > create mode 100644 security/keys/pgp_library.c > create mode 100644 security/keys/pgp_parser.h > create mode 100644 security/keys/pgp_preload.c > create mode 100644 security/keys/pgp_pubkey_sig.c > create mode 100644 security/keys/pgp_sig_parser.c > create mode 100644 security/keys/public_key.c > create mode 100644 security/keys/public_key.h > -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 4:05 ` James Morris @ 2011-12-09 9:17 ` David Howells 2011-12-09 9:35 ` James Morris 2011-12-09 14:20 ` Arjan van de Ven 0 siblings, 2 replies; 17+ messages in thread From: David Howells @ 2011-12-09 9:17 UTC (permalink / raw) To: James Morris Cc: dhowells, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, arjan, alan James Morris <jmorris@namei.org> wrote: > > Could you pull my module signing code into the security tree? The patches can > > be viewed here: > > I'm getting this build error: > > make[1]: *** No rule to make target `kernel.pub', needed by > `kernel/modsign-pubkey.o'. Stop. If you turn module signing on, you have to supply keys for it to sign things with and to later verify the signature... I wonder what the best way to deal with that is... I guess make allyesconfig and make allmodconfig are going to break otherwise. David ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 9:17 ` David Howells @ 2011-12-09 9:35 ` James Morris 2011-12-09 14:20 ` Arjan van de Ven 1 sibling, 0 replies; 17+ messages in thread From: James Morris @ 2011-12-09 9:35 UTC (permalink / raw) To: David Howells Cc: linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, arjan, alan On Fri, 9 Dec 2011, David Howells wrote: > James Morris <jmorris@namei.org> wrote: > > > > Could you pull my module signing code into the security tree? The patches can > > > be viewed here: > > > > I'm getting this build error: > > > > make[1]: *** No rule to make target `kernel.pub', needed by > > `kernel/modsign-pubkey.o'. Stop. > > If you turn module signing on, you have to supply keys for it to sign things > with and to later verify the signature... > > I wonder what the best way to deal with that is... I guess make allyesconfig > and make allmodconfig are going to break otherwise. Create a dummy key? -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 9:17 ` David Howells 2011-12-09 9:35 ` James Morris @ 2011-12-09 14:20 ` Arjan van de Ven 2011-12-09 14:31 ` James Morris 2011-12-10 9:49 ` Geert Uytterhoeven 1 sibling, 2 replies; 17+ messages in thread From: Arjan van de Ven @ 2011-12-09 14:20 UTC (permalink / raw) To: David Howells Cc: James Morris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/9/2011 1:17 AM, David Howells wrote: > James Morris <jmorris@namei.org> wrote: > >>> Could you pull my module signing code into the security tree? >>> The patches can be viewed here: >> >> I'm getting this build error: >> >> make[1]: *** No rule to make target `kernel.pub', needed by >> `kernel/modsign-pubkey.o'. Stop. > > If you turn module signing on, you have to supply keys for it to > sign things with and to later verify the signature... > > I wonder what the best way to deal with that is... I guess make > allyesconfig and make allmodconfig are going to break otherwise. the best way to deal is to have KBUILD generate a key on demand ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJO4hkeAAoJEEHdSxh4DVnEWZoIAIJ8MvXcW6B7MbO5V8J7RjDc h04/xt6UXdg/IZqOFNvVSxNHgfNR2PeRHpNH6kbi8ftX4rp18U7n1y6+WHoMPEHQ s7+NZQGzhh6TZeVzzAKIKLASnbDIysf8N6eKt0wRRygg3ipj891kMDCLKrkPY3sj 9NL6xOp7uo6p0C9V70UXmO2tqwvtlKnIcD+DcCalnJN+9/pBbhnm13vGFIbTJYsr uB38DHG4klJceRX+S3CUjFIub1YzW72TevBsenSLdCLBXOHKI/YXqX5uDZyl9pal nguULAR4Blmv61xN7XJyIJLUmjjy4K7ppR1zxePGVGIalaDqs60PDKJ6ipHoL6o= =gfR7 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 14:20 ` Arjan van de Ven @ 2011-12-09 14:31 ` James Morris 2011-12-09 18:06 ` David Howells 2011-12-10 9:49 ` Geert Uytterhoeven 1 sibling, 1 reply; 17+ messages in thread From: James Morris @ 2011-12-09 14:31 UTC (permalink / raw) To: Arjan van de Ven Cc: David Howells, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan On Fri, 9 Dec 2011, Arjan van de Ven wrote: > the best way to deal is to have KBUILD generate a key on demand ;-) Yes -- I'd like to see this code do something useful by default when enabled, so yes, create a local key during the build, possibly configurable via kconfig. Is there any reason not to sign and verify kernel modules by default? - James -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 14:31 ` James Morris @ 2011-12-09 18:06 ` David Howells 2011-12-09 18:18 ` Arjan van de Ven 0 siblings, 1 reply; 17+ messages in thread From: David Howells @ 2011-12-09 18:06 UTC (permalink / raw) To: James Morris Cc: dhowells, Arjan van de Ven, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan James Morris <jmorris@namei.org> wrote: > Is there any reason not to sign and verify kernel modules by default? If you don't have an entropy source, your build can hang if it's waiting for gpg to generate a key. You need to run rngd to get around this. David ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 18:06 ` David Howells @ 2011-12-09 18:18 ` Arjan van de Ven 2011-12-09 18:47 ` David Howells 0 siblings, 1 reply; 17+ messages in thread From: Arjan van de Ven @ 2011-12-09 18:18 UTC (permalink / raw) To: David Howells Cc: James Morris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan On 12/9/2011 10:06 AM, David Howells wrote: > James Morris <jmorris@namei.org> wrote: > >> Is there any reason not to sign and verify kernel modules by default? > > If you don't have an entropy source, your build can hang if it's waiting for > gpg to generate a key. You need to run rngd to get around this. ... the temp key can use /dev/urandom. seriously, /dev/urandom for one time, temp keys is not bad (if you care about the difference, you better provide your own real key) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 18:18 ` Arjan van de Ven @ 2011-12-09 18:47 ` David Howells 2011-12-09 18:49 ` Arjan van de Ven 2011-12-09 19:41 ` [Keyrings] " Daniel Kahn Gillmor 0 siblings, 2 replies; 17+ messages in thread From: David Howells @ 2011-12-09 18:47 UTC (permalink / raw) To: Arjan van de Ven Cc: dhowells, James Morris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan Arjan van de Ven <arjan@linux.intel.com> wrote: > ... the temp key can use /dev/urandom. > seriously, /dev/urandom for one time, temp keys is not bad > (if you care about the difference, you better provide your own real key) Can you tell gpg which random device to use? David ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 18:47 ` David Howells @ 2011-12-09 18:49 ` Arjan van de Ven 2011-12-09 18:59 ` David Howells 2011-12-09 19:41 ` [Keyrings] " Daniel Kahn Gillmor 1 sibling, 1 reply; 17+ messages in thread From: Arjan van de Ven @ 2011-12-09 18:49 UTC (permalink / raw) To: David Howells Cc: James Morris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan On 12/9/2011 10:47 AM, David Howells wrote: > Arjan van de Ven <arjan@linux.intel.com> wrote: > >> ... the temp key can use /dev/urandom. >> seriously, /dev/urandom for one time, temp keys is not bad >> (if you care about the difference, you better provide your own real key) > > Can you tell gpg which random device to use? > > David see http://www.gnupg.org/documentation/manuals/gnupg-devel/Unattended-GPG-key-generation.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 18:49 ` Arjan van de Ven @ 2011-12-09 18:59 ` David Howells 0 siblings, 0 replies; 17+ messages in thread From: David Howells @ 2011-12-09 18:59 UTC (permalink / raw) To: Arjan van de Ven Cc: dhowells, James Morris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan Arjan van de Ven <arjan@linux.intel.com> wrote: > see > http://www.gnupg.org/documentation/manuals/gnupg-devel/Unattended-GPG-key-generation.html "%transient-key"? David ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Keyrings] [GIT PULL] Crypto keys and module signing 2011-12-09 18:47 ` David Howells 2011-12-09 18:49 ` Arjan van de Ven @ 2011-12-09 19:41 ` Daniel Kahn Gillmor 1 sibling, 0 replies; 17+ messages in thread From: Daniel Kahn Gillmor @ 2011-12-09 19:41 UTC (permalink / raw) To: David Howells Cc: Arjan van de Ven, keyrings, linux-kernel, linux-security-module, dmitry.kasatkin, alan [-- Attachment #1: Type: text/plain, Size: 528 bytes --] On 12/09/2011 01:47 PM, David Howells wrote: > Arjan van de Ven <arjan@linux.intel.com> wrote: > >> ... the temp key can use /dev/urandom. >> seriously, /dev/urandom for one time, temp keys is not bad >> (if you care about the difference, you better provide your own real key) > > Can you tell gpg which random device to use? Depending on the version of gpg, supplying either --quick-random or --debug-quick-random should use a cheaper PRNG. I think this is an undocumented feature, though. hth, --dkg [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 1030 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-09 14:20 ` Arjan van de Ven 2011-12-09 14:31 ` James Morris @ 2011-12-10 9:49 ` Geert Uytterhoeven 1 sibling, 0 replies; 17+ messages in thread From: Geert Uytterhoeven @ 2011-12-10 9:49 UTC (permalink / raw) To: Arjan van de Ven Cc: David Howells, James Morris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan On Fri, Dec 9, 2011 at 15:20, Arjan van de Ven <arjan@linux.intel.com> wrote: >> I wonder what the best way to deal with that is... I guess make >> allyesconfig and make allmodconfig are going to break otherwise. > > the best way to deal is to have KBUILD generate a key on demand ;-) Or provide a default key with the kernel, cfr. all the other "*.shipped" files? No entropy source needed. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-07 14:47 [GIT PULL] Crypto keys and module signing David Howells 2011-12-09 4:05 ` James Morris @ 2011-12-10 11:42 ` Arkadiusz Miśkiewicz 2011-12-10 12:50 ` David Howells 2011-12-10 18:54 ` Arjan van de Ven 1 sibling, 2 replies; 17+ messages in thread From: Arkadiusz Miśkiewicz @ 2011-12-10 11:42 UTC (permalink / raw) To: David Howells Cc: jmorris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, arjan, alan On Wed, Dec 7, 2011 at 3:47 PM, David Howells <dhowells@redhat.com> wrote: > > Hi James, > > Could you pull my module signing code into the security tree? The patches can > be viewed here: > > http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/devel If I understand it is not possible to sign modules after they are built and load keys without actually rebuilding kernel? For distro kernel the public and secret keys have to be available publicly, right? Otherwise people using distro kernels won't be able to build own signed modules for use with that distro kernel. Then I as admin have to rebuild the kernel to get my own keys in and prevent other, "unapproved" modules to be loaded. Correct? Would be nice if the modules could be signed/re-signed after being build and prehaps kernel could load keys from initramfs? Then everyone could use own keys on distro kernels without need to rebuild the thing. I think I'm missing something :) -- Arkadiusz Miśkiewicz ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-10 11:42 ` Arkadiusz Miśkiewicz @ 2011-12-10 12:50 ` David Howells 2011-12-12 14:12 ` Nick Bowler 2011-12-10 18:54 ` Arjan van de Ven 1 sibling, 1 reply; 17+ messages in thread From: David Howells @ 2011-12-10 12:50 UTC (permalink / raw) To: =?ISO-8859-2?Q?Arkadiusz_Mi=B6kiewicz?= Cc: dhowells, jmorris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, arjan, alan Arkadiusz Miśkiewicz <a.miskiewicz@gmail.com> wrote: > If I understand it is not possible to sign modules after they are built Well, modules are signed after they're built. It's a matter of creating a detached signature for the parts of the module file you want to protect and then inserting the signature into the module file. I've created a way to do this as part of the build process, but previously we had the spec file do it during the kernel RPM build. > and load keys without actually rebuilding kernel? Well, yes and no. The way we have used up to now involves building a set of public keys into the kernel so that modules can be verified with them during loading. We could make a way to load extra keys, but how does the kernel know it can trust those keys? With the new mechanism in the patches I've submitted, there is the possibility of using a cryptographic key storage hardware (such as a TPM) to directly store either extra public keys that you want to be able to verify modules with, or to hold a key you sign the extra public keys with. That way you can have modules signed with the kernel's build-time temporary key and also have modules signed with other keys that are trusted by the administrator. > For distro kernel the public and secret keys have to be available publicly, > right? No. The public key has to be publically available, but the secret key must be kept, well, secret - otherwise there's no point. If anyone can sign a module to run on your system, then the signature mechanism may as well not be there. RHEL keeps the secret key as secret as it possibly can by generating a new one each time a kernel RPM is built and then it's deleted afterwards when the BUILD directory is cleaned up. No record of the secret key is kept. It's not easy to have the buildfarm save the secret key in a database somewhere as anyone who gets hold of a RHEL kernel SRPM and wants to build it mustn't find the build fails because the secret-key-save mechanism doesn't work. Besides - you don't want it quietly saving your privately built secret key to Red Hat's big database, right? > Otherwise people using distro kernels won't be able to build own signed > modules for use with that distro kernel. That's the whole point... To a point. You can still load unsigned modules, but it makes a fuss in the syslog, and you can block unsigned modules. Hopefully at some time in the future, as mentioned above, you'll be able to use hardware for this. > Then I as admin have to rebuild the kernel to get my own keys in and prevent > other, "unapproved" modules to be loaded. Correct? Correct. You could, theoretically, extract the public keys from the kernel you're rebuilding and include those too, but it's messy. > Would be nice if the modules could be signed/re-signed after being build That's relatively straight forward. You can strip the existing signatures and replace them with your own. The modules are really signed *after* being built - after all, you don't know what it is you're going to be signing until after the things are built. > and prehaps kernel could load keys from initramfs? How do you trust the keys? If you have a TPM, then yes you can do that. In fact, how do you trust the public key compiled into the kernel for that matter? Ideally, the bootloader would have to check that the kernel image hasn't been tampered with. That's easier than checking the initramfs as the kernel is not changed after building, whereas the initramfs is. > Then everyone could use own keys on distro kernels without need to rebuild > the thing. > > I think I'm missing something :) Perhaps I can summarise: (1) The whole point of having a secret key is that you tell as few people as absolutely possible what it is. (2) Public keys have to be trusted in order for you to use them. (3) Cryptography is, by its very nature, inconvenient. But it only works if you inconvenience people who shouldn't have access more than you inconvenience those who should. David ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-10 12:50 ` David Howells @ 2011-12-12 14:12 ` Nick Bowler 0 siblings, 0 replies; 17+ messages in thread From: Nick Bowler @ 2011-12-12 14:12 UTC (permalink / raw) To: David Howells Cc: =?ISO-8859-2?Q?Arkadiusz_Mi=B6kiewicz?=, jmorris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, arjan, alan On 2011-12-10 12:50 +0000, David Howells wrote: > Arkadiusz Miśkiewicz <a.miskiewicz@gmail.com> wrote: > > and prehaps kernel could load keys from initramfs? > > How do you trust the keys? If you have a TPM, then yes you can do that. Exactly the same way you trust the kernel image itself. If you can't trust the integrity of your initramfs (and thus the keys stored within it), then you also cannot trust the integrity of the kernel image and thus this whole signing exercise is moot. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [GIT PULL] Crypto keys and module signing 2011-12-10 11:42 ` Arkadiusz Miśkiewicz 2011-12-10 12:50 ` David Howells @ 2011-12-10 18:54 ` Arjan van de Ven 1 sibling, 0 replies; 17+ messages in thread From: Arjan van de Ven @ 2011-12-10 18:54 UTC (permalink / raw) To: Arkadiusz Miśkiewicz Cc: David Howells, jmorris, linux-security-module, keyrings, linux-kernel, dmitry.kasatkin, zohar, alan -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/2011 3:42 AM, Arkadiusz Miśkiewicz wrote: > On Wed, Dec 7, 2011 at 3:47 PM, David Howells <dhowells@redhat.com> > wrote: >> >> Hi James, >> >> Could you pull my module signing code into the security tree? >> The patches can be viewed here: >> >> http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=shortlog;h=refs/heads/devel > >> > If I understand it is not possible to sign modules after they are > built and load keys without actually rebuilding kernel? only if the end user chooses to enforce the signature. > > For distro kernel the public and secret keys have to be available > publicly, right? Otherwise people using distro kernels won't be > able to build own signed modules for use with that distro kernel. That's a distro choice, but... again: only if the user chooses to enforce the signature. Very few people actually build their own modules, and for the people that don't, they can chose to harden their server by only allowing signed (eg distro shipped) modules. For those who prefer to build a few other things and still want security, they can also rebuild the kernel. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJO46r4AAoJEEHdSxh4DVnE39cIALufzQHXgIycaRnImtEWSPrq PN5ac052lb59YGEbSsUF/Er/SOLfdwJQbD2Gz2/0QCPWfpb64pozDDwFh1IhvvEp q4D/1wAJBXOaEj1FESPxHkbwvdYe701pgLq0ERQu4SSx69wNMFXNMmp06Jbxuujp ZRhQcuJQsd76mJi8MZ2f9qnzR+3MQ9zFGK2alqDfb0WiELBc+Cz1nj2tCXrB5AFa 7osPZJK2iBcD+2sfryMEuJWxOjWxm/ZiEz2oIV0vRtnozVEAIYaeJ2Xe6n72Zj3W AuAGbnfE9j7yzBVz+9KOZEd2DW7MF7Xns4Vn1/1y6W0h0RsXTq15LIXApJL760I= =fCSX -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-12-12 14:13 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-07 14:47 [GIT PULL] Crypto keys and module signing David Howells 2011-12-09 4:05 ` James Morris 2011-12-09 9:17 ` David Howells 2011-12-09 9:35 ` James Morris 2011-12-09 14:20 ` Arjan van de Ven 2011-12-09 14:31 ` James Morris 2011-12-09 18:06 ` David Howells 2011-12-09 18:18 ` Arjan van de Ven 2011-12-09 18:47 ` David Howells 2011-12-09 18:49 ` Arjan van de Ven 2011-12-09 18:59 ` David Howells 2011-12-09 19:41 ` [Keyrings] " Daniel Kahn Gillmor 2011-12-10 9:49 ` Geert Uytterhoeven 2011-12-10 11:42 ` Arkadiusz Miśkiewicz 2011-12-10 12:50 ` David Howells 2011-12-12 14:12 ` Nick Bowler 2011-12-10 18:54 ` Arjan van de Ven
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.