efi: Add support for shim binaries used during snapd spread tests #266
Conversation
Snapd re-signs production shim and grub binaries (previously signed by Microsoft and Canonical) with a snakeoil key, so recognize this as part of the Microsoft hierarchy during testing. Some tests also recompile our patched shim v15, which we use an image digest match to recognize it as having patches backported from 15.2. Recognize any shim v15 signed with the snakeoil key as being supported during testing. Some tests also replace the .vendor_cert section of a production shim with an ephemeral certificate, and sign a production grub binary previously signed by Canonical with the corresponding key, so recognize these grubs as having the chainloader modifications during testing.
Grub detection will be fixed separately in canonical#268
chrisccoulson
changed the title
chrisccoulson
force-pushed
the
efi-support-snapd-test-binaries
branch
from
9e9fdc6 to
80feeaa
Compare
| bytes.Equal(authority.issuer, cert.RawIssuer) && | ||
| bytes.Equal(authority.authorityKeyId, cert.AuthorityKeyId) && | ||
| authority.signatureAlgorithm == cert.SignatureAlgorithm { |
There was a problem hiding this comment.
for non snakeoil keys both sides here are going to be empty?
There was a problem hiding this comment.
One side will always have all fields. I did consider trying to accommodate this but it looked over complicated and it would only make a difference in an edge case - ie, a shim that embeds the Microsoft CA as a vendor certificate. In this case, it would be added twice, which isn't really a problem anyway.
| // secureBootNamespaceRules, only during testing. This also supports the case where the | ||
| // specified authority is the signer. | ||
| func withSelfSignedSignerOnlyForTesting(subject, subjectKeyId []byte, publicKeyAlgorithm x509.PublicKeyAlgorithm, signatureAlgorithm x509.SignatureAlgorithm) secureBootNamespaceOption { | ||
| if !snapdenvTesting() { |
There was a problem hiding this comment.
just to double check: these are relevant only on the policy generation side? also to manipulate this we need to influence a root-running service environment? also ultimately what can be booted with is controlled by secureboot?
maybe some of this consideration should go in a comment somewhere?
There was a problem hiding this comment.
Yes, this is only relevant when generating policies, and just required for image detection. You can still use an API to generate a policy for binaries signed by any key, it's just that some of the edge cases in the detection might not work and you could end up with the wrong digests.
Snapd re-signs production shim and grub binaries (previously signed by Microsoft and Canonical) with a snakeoil key, so recognize this as part of the Microsoft hierarchy during testing.
Some tests also recompile our patched shim v15, which we use an image digest match to recognize it as having patches backported from 15.2. Recognize any shim v15 signed with the snakeoil key as being supported during testing.
#268 will contain changes required for grub.