launchpad archive-generated kmod signing keys should use extendedKeyUsage 1.3.6.1.4.1.2312.16.1.2
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Undecided
|
Andy Whitcroft |
Bug Description
The launchpad key generation code currently generates keys with keyUsage=
In consultation with the Security Team, the constraints applied to the key used for signing of dkms modules on end-users' systems include 1.3.6.1.
As per /usr/lib/
# We use extended key usage information to limit what this auto-generated
# key can be used for.
#
# codeSigning: specifies that this key is used to sign code.
#
# 1.3.6.1.
# only. See https:/
#
extendedKeyUsage = codeSigning,
Launchpad should implement this same policy for its kmod signing keys, to support granting least privilege to keys that should never be used for signing bootloaders or kernels.
(No firmware implementations are known to recognize this key usage OID; so such keys installed to db instead of MOK would still be trusted by the firmware for signing of all UEFI objects. So kmodsign keys should be registered in MOK and not in db where possible, to take advantage of this information.)
Related branches
- Colin Watson: Approve
-
Diff: 124 lines (+64/-18)2 files modifiedlib/lp/archivepublisher/signing.py (+36/-18)
lib/lp/archivepublisher/tests/test_signing.py (+28/-0)
tags: | added: id-5b11b18e5506de3edd3f0651 |
Changed in launchpad: | |
status: | New → In Progress |
assignee: | nobody → Andy Whitcroft (apw) |
tags: | added: lp-soyuz soyuz-publish |
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
Fixed in stable r18744 <http:// bazaar. launchpad. net/~launchpad- pqm/launchpad/ stable/ revision/ 18744>.