Closed Cornelicorn closed 5 months ago
Or defaulting to only generating missing keys and providing a cmdline switch --overwrite / overriding unless --no-overwrite was given?
Hrm, I think I'm not happy with the dbx
implementation and need to revisit it.
It shouldn't really be creating a key like this.
Even a bit worse:
# sbctl enroll-keys --custom --yolo --partial PK
Enrolling keys to EFI variables...✗
couldn't sync keys: open /usr/share/secureboot/keys/dbx/dbx.pem: no such file or directory
The dbx functionality is completely broken and does not work at all. The current implementation simply tries to load pem files from dbx folders, just like PK/KEK, but dbx dbs contain also (mostly/only?) SHA256 checksums, not certificates. There is no support in sbctl for loading hashes from files, only certificates - although most of the required functionality seems to be already implemented through TPM event log functionality.
Until dbx actually works, I would suggest removing/hiding the functionality. Current version is broken as it REQUIRES dbx.pem (but loading only certificates / pem files to dbx makes little sense, we need to load checksums) - the ugly workaround is using -p/--partial and enrolling one by one...
but dbx dbs contain also (mostly/only?) SHA256 checksums, not certificates.
Not completely correct. The uefi.org standard dbx file contains certs and checksums, but making a new key just to have something inside dbx doesn't work very well.
Until dbx actually works, I would suggest removing/hiding the functionality. Current version is broken as it REQUIRES dbx.pem (but loading only certificates / pem files to dbx makes little sense, we need to load checksums) - the ugly workaround is using -p/--partial and enrolling one by one...
Sure, I just need to sit down with it. In the future we can implement a sbctl revoke
thing I guess.
Reverted the dbx change here: https://github.com/Foxboron/sbctl/commit/ff5369185b251c3265312a4c2eb8ed759ef197ad
I'm inclined to work on the dbx support at a later point. But it should probably be specially treated and kept as a revocation database. Not an actual key store.
Also reproducible on my two Arch machines with sbctl 0.12:
$ sbctl status
Installed: ✓ sbctl is installed
$ sbctl reset
✓ Removed Platform Key!
$ sbctl enroll-keys --yolo
Enrolling keys to EFI variables...✗
couldn't sync keys: open /usr/share/secureboot/keys/dbx/dbx.pem: no such file or directory
When downgrading to 0.11, the issue is gone:
$ sbctl enroll-keys --yolo
Enrolling keys to EFI variables...✓
Enrolled keys to the EFI variables!
I'll do a new release this week
Hi @Foxboron, would you be able to do the new release soon?
@googol Yes, sorry.
I have been busy rewriting the implementation of Microsoft Authenticode that sbctl
relies on to be more easily maintainable, and then I wound up trying out Baldurs Gate. Suddenly the weekend was over :upside_down_face:
I'll get it done this week!
Ohh you fell into that trap :D I understand, no worries!
I can confirm that I was able to re-enroll with the latest release :)
Ah yes, this works now again.
Using 0.12, re-enrolling the keys using
sbctl reset
andsbctl reset-keys
fails withcouldn't sync keys: open /usr/share/secureboot/keys/dbx/dbx.pem
. This is logical, since this key is missing. However, runningsbctl create-keys
overwrites the existing keys, so you would need to resign everything up to this point, which I find impractical. Since there isrotate-keys
, maybecreate-keys
could be changed to only create missing keys or the enrollment oculd be adjusted so it doesn't require the dbx key (I'm also not quite sure what the dbx included might be used for as long as there is no way to revoke something using sbctl directly)?I'm happy to submit a patch for any approach, just wanted to discuss the best approach beforehand (i.e. only generating missing keys (my preference) or not enrolling dbx)