On 27.09.2023 19:02, cagsm wrote:
On Wed, Sep 27, 2023 at 3:22 PM Andrei Borzenkov
wrote: embedded in the shim? is this some superior security means in contrast to that MOK stuff? I do not understand this question, I do not even understand if this is a question or rant.
no i only was trying to still undstand this situation. is everything at the end of the day a MOK and stored in this MOK database? because on my leap 15.5 machine as this thread shows, there is only that suse enterprise secureboot key stored there.
Do you have openSUSE-signkey-cert package installed? What is the content of /etc/uefi/certs?
i was only asking if the shim mechanism maybe is having additional keys embedded inside itself and stored elsewhere or so. this reminds me of UEFIs (bioses) that also have some kind of menu about root keys of microsoft for all this secureboot stuff and some allowing the user to select additional keys and enroll via uefi etc. i now wonder where actually this MOK database or this UEFI way to enroll all is stored at the end of the day.
It is stored in several UEFI variables with GUID 605dab50-e046-4300-abb6-3dd810dd8b23 and names MokList, MokListTrusted, MokListX (could be more). These variables are visible and accessible only during boot, which explains why certificates cannot be enrolled directly. shim copies them into MokListRT etc, so that their content can be read after boot.
i never managed to look into this NVRAM and stuff if thats anything got to do with it. where are these stores to begin with as some? they need to be very early accessible etc.
does this MOK stuff (vanilla opensuse 15.5 situation, for this virtualbox and leap 15.5) actually work the very same way with FDE (full disc encryption)? then the MOK database and these keys cant be stored on disk i guess and need to be stored outside of FDE? then again there is this fat? fat32? partition in the UEFI world that always needs to be accessible or something?
so many confusing or complex things.
so is this really a virtual box package bug in opensuse leap 15.5, is
I do not have 15.5 right now, but on 15.4 openSUSE-signkey-cert is recommended by minimal base pattern. And openSUSE-signkey-cert enrolls
Same on 15.5.
its key when it is installed. It does require explicit user intervention during the next boot which is easy to miss or to misunderstand and ignore.
But yes, in general I believe this is the wrong way to do it. Each package that installs signed modules should at least recommend a package containing its signing key.
i wonder how can I sort out this situation now to arrive at the real actually intended situation of 15.5 (if there is any?
Just enroll /etc/uefi/certs/1F673297-kmp.crt mokutil --import /etc/uefi/certs/1F673297-kmp.crt and reboot.
that german blog also described the shortcomings early 2022 though). i have not yet memorized the situation with the keys for MOK, those .der files or crypto stuff, there are supposedly two files if the user creates keys of their own to enroll into MOK and one needs to go wherever and the other needs to go another place or something so I understood briefly so far.
ty