Technik Gurus

Diese Seite ist nicht editierbar. Du kannst den Quelltext sehen, jedoch nicht verändern. Kontaktiere den Administrator, wenn du glaubst, dass hier ein Fehler vorliegt.
====== Secure Boot ======

Im Zusammenhang mit diesen Artikel verwendete Hardware:

https://www.heckpiet.net/dell-wyse-5070-thin-client-als-home-sever

Im UEFI lässt sich SecureBoot aktivieren/deaktivieren. Oft ist parallel dazu auch die Konfiguration von TPM(TrustedPlattformModul) möglich. 

Auf Rechnern mit UEFI und ohne aktivierter rückwärts-Kompatibilität zum alten BIOS Standard können nur Datenträger mit Betriebssystemen gestartet werden, welche eine entsprechende Boot Partition haben.

Hier ist die Boot Partition die 1. Partition auf dem Datenträger /dev/sda, also unter Linux mit ''/dev/sda1''
angesprochen.

<code>
iglu:~ # parted -l
Model: VMware Virtual disk (scsi)
Disk /dev/sda: 53.7GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  538MB   537MB   fat32                 boot, esp
 2      538MB   51.5GB  51.0GB  btrfs
 3      51.5GB  53.7GB  2149MB  linux-swap(v1)        swap
</code>

Die Partitionstabelle muss **gpt** sein, das Dateisystem FAT und bei Flags muss ''boot'', ''esp'' stehen.


Zu beachten ist, das auf einem PC mit mehreren Betriebssystemen es dazu kommen kann das ein System nicht mehr bootet mit der Meldung "Security Validation Failed".


==== Fehlermeldungen ====

Fehlermeldungen die auftreten können:

<code>
ERROR verification failed 0x1A security violation

Failed to load image: Security Policy Violation

Failed to open \EFI\BOOT\mmx64.efi Not Found

error:shim_lock protocol not found

bad signature: (hd0, ecx4) /database2/boot/kernel_mapping)
</code>


===== mokutil =====

Eine **Abhilfe** bietet hier das ''mokutil''.

Es ist evtl. nötig die default Keys im UEFI wieder herszustellen, der Secure BootStick verlangt evtl. den Standard Microsoft Key

Folgende Kommandos zeigen zumindest:

  mokutil --kek

  * [key 1] = C=US, ST=Texas, L=Round Rock, O=Dell Inc., CN=Dell Inc. Platform Key
  * [key 2] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root

  mokutil --db

  * [key 1] = C=US, ST=Texas, L=Round Rock, O=Dell Inc., CN=Dell Inc. Key Exchange Key
  * [key 2] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
  * [key 3] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010


  mokutil --dbx

  * [key 1] = C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
  * [key 2] = [SHA-256] 80b4d96931b... ewig lang ...856967df8e
  
  
Ansonsten gilt:
Secure Boot deaktivieren und die folgenden Kommandos ausführen. Falls sich Secure Boot nicht deaktivieren lässt (Dell), dann ein System starten, welches mit den Standard Signaturen starten kann. In meinem Fall hatte OpenSuse neuere Keys bzw. seine eigenen Suse Key im NVRAM des UEFI Chips geladen und wohl auch die Secure Boot Advanced Targeting (SBAT) aktualisiert so das ältere Micosoft Keys nicht mehr funktionieren, sondern nur neuere Versionen davon - Hauptgrund warum der Boot-Stick nicht mehr startet.


folgender Kommando zeigt nur einen **[key 1]** Issuer: CN=SUSE Linux Enterprise Secure Boot CA - so sieht es auch aus wenn es funktioniert.

  mokutil --list-enrolled


Disabling/re-enabling Secure Boot:

  mokutil --disable-validation or mokutil --enable-validation
  mokutil --reset
  mokutil --set-sbat-policy previous / delete
  
Choose a password between 8 and 16 characters long. Enter the same password to confirm it. Reboot. When prompted, press a key to perform MOK management. Select „Change Secure Boot state“. Enter each requested character of your chosen password to confirm the change. Note that you have to press Return/Enter after each character.

- Select „Yes“. 
- Select „Reboot“. 

Im MOK Manager der direkt nach dem reboot aufgerufen wird alles löschen bzw. deaktiveren, MOK List delete und Validation deaktiveren.

  
Wenn es funktioniert, dann sollte folgendes angezeigt werden:

  mokutil --list-sbat-revocations

  sbat,1,2022052400
  grub,2

==== Interessant aber ungetestet ====

Manipulate the MOK blacklist

  mokutil --mokx
  


===== shim Bootloader =====
Wird nach GRUB aufgerufen wenn festgstellt wird das Standard Bootloader nicht signiert ist
Der shim Bootloader benötigt eine UEFI kompatible GPT Boot Partition sonst kommt die Meldung

  # shim-install 
  No valid EFI partition


The default boot loader used by openSUSE on UEFI systems is grub2. When in secure boot mode, an additional boot loader called 'shim' is used too. Instead of directly calling grub2 in that mode the firmware first loads 'shim'. 'shim' carries a signature by Microsoft in order to be recognized by the firmware. 'shim' in turn knows about the openSUSE certificate that was used to sign grub2. grub2 then is able to load linux kernels that are also signed by the openSUSE certificates. After loading the Linux kernel the scope of secure boot ends. The linux kernel used in openSUSE does not impose additional restrictions.

In order to allow having custom boot loaders as well as custom kernels shim offers a way to import custom signatures. The program 'MokManager' is used for that purpose. When 'shim' is instructed to load a binary that is not signed by a well known entity it calls into MokManager which allows to import certificates into the database of well known signature issuers. 


Damit beim Suse Updates kein zu neuer restiktiver shim aktiv wird wurden nun
sicherheitshalber Updates für shim blockiert:

<code>
iglu:~ # zypper la shim
Specified lock has been successfully added.

iglu:~ # zypper ll

# | Name | Type    | Repository | Comment
--+------+---------+------------+--------
1 | shim | package | (any)      | 
</code>




===== efiboot =====

<code>
apt list "uefi"
Auflistung… Fertig
...
uefitool-cli/stable 0.28.0-1 arm64
uefitool-cli/stable 0.28.0-1 armhf
uefitool/stable 0.28.0-1 arm64
uefitool/stable 0.28.0-1 armhf
</code>

~ # efiboot
  efibootdump  efibootmgr



===== sbsigntools =====

Canonical EFI binary signing tools

  sbsigntools




===== Funktion Beobachtung =====

Boot funktioniert mit ECOS Stick

==== UEFI ====

UEFI Einstellung:

TPM = deaktiviert

Secure Boot = aktiviert aber auf alles erlauben gesetzt. Schlüssel stehen auf Custom Mode enabled, d.h. man kann Schlüssel setzen und die Einstellungen bleiben, evtl. hier sogar keinen Custom Mode damit immer der Ursprung fest eingestellt bleibt? Z.B. bei Suse Updates.


==== SUSE ====


=== bootctl status ===

<code>
systemd-boot not installed in ESP.
System:
     Firmware: n/a (n/a)
  Secure Boot: disabled
   Setup Mode: setup
 TPM2 Support: no
 Boot into FW: supported
</code>


=== mokutil ===

  mokutil --list-sbat-revocations
  
  sbat,1,2022052400
  grub,2
  
  mokutil --sb-state
   
  SecureBoot disabled   <-- sagt disabled im UEFI steht enabled
  Platform is in Setup Mode
  

Erstaunlich, Kommandos liefern nichts zurück, kein Plattform Key? Im UEFI nur dbx gelöscht.

  mokutil --pk

Dieser Kommando liefert nun 2 key zurück, in Suse keine Updates eingespielt, kann nur vom BootStick sein.

  mokutil --dbx


Kommando mit ''--list-enrolled'' liefert wie zu erwarten den SUSE Key zurück

<code>
  mokutil --list-enrolled
  
  [key 1]
  ...
  Issuer: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
        Validity
            Not Before: Apr 18 14:33:41 2013 GMT
            Not After : Mar 14 14:33:41 2035 GMT
        Subject: CN=SUSE Linux Enterprise Secure Boot CA, C=DE, L=Nuremberg, O=SUSE Linux Products GmbH, OU=Build Team/emailAddress=build@suse.de
</code>


===== efi-readvar =====

Kommando ''efi-readvar'' liefert:
  
  Variable PK has no entries
  Variable dbx has no entries
  Variable MokList has no entries
  
bei KEK: wird was angezeigt List 0 und List1
bei db: wird was angezeigt List 0, List 1 und List 2


Auslesen von dbx und speichern in Datei dbx.esl ?

  efi-readvar -v dbx -o dbx.esl


=== efibootmgr ===

Kommando ''efibootmgr -v'' zeigt natürlich bei meiner angesteckten USB Festplatte und gestarteten SUSE meine 
Suse Start Partition ganz oben. Wenn meine Festplatte weg ist, würde der folgende Eintrag starten:

  Boot0004* RH2   PciRoot(0x0)/Pci(0x15,0x0)/USB(2,0)/HD(1,GPT,b90c1753-d520-47c9-a136-5a0ad43e2cd2,0x1000,0x5000)/File(\EFI\BOOT\BOOTx64.EFI)
  

=== fwupdmgr ===
  
  fwupdmgr get-history
  No history
  
  
Zeigt eine Liste der verbauten / angeschlossenen Geräte mit Update Informationen. Liste habe ich bereits gespeichert.

  fwupdmgr get-devices
  

===== keytool =====

<code>
tux@iglu:/Downloads # keytool -printcert -file microsoft-uefica-public.cer 
Owner: CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US
Issuer: CN=Microsoft Corporation Third Party Marketplace Root, O=Microsoft Corporation, L=Redmond, ST=Washington, C=US
Serial number: 6108d3c4000000000004
Valid from: Mon Jun 27 23:22:45 CEST 2011 until: Sat Jun 27 23:32:45 CEST 2026
Certificate fingerprints:
         SHA1: 46:DE:F6:3B:5C:E6:1C:F8:BA:0D:E2:E6:63:9C:10:19:D0:ED:14:F3
         SHA256: 48:E9:9B:99:1F:57:FC:52:F7:61:49:59:9B:FF:0A:58:C4:71:54:22:9B:9F:8D:60:3A:C4:0D:35:00:24:85:07
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions: 

#1: ObjectId: 1.3.6.1.4.1.311.20.2 Criticality=false
0000: 1E 0A 00 53 00 75 00 62   00 43 00 41              ...S.u.b.C.A


#2: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false
0000: 02 03 01 00 01                                     .....


#3: ObjectId: 1.3.6.1.4.1.311.21.2 Criticality=false
0000: 04 14 F8 C1 6B B7 7F 77   53 4A F3 25 37 1D 4E A1  ....k..wSJ.%7.N.
0010: 26 7B 0F 20 70 80                                  &.. p.


#4: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
AuthorityInfoAccess [
  [
   accessMethod: caIssuers
   accessLocation: URIName: http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt
]
]

#5: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 45 66 52 43 E1 7E 58 11   BF D6 4E 9E 23 55 08 3B  EfRC..X...N.#U.;
0010: 3A 22 6A A8                                        :"j.
]
]

#6: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#7: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
  [DistributionPoint:
     [URIName: http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl]
]]

#8: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
  DigitalSignature
  Key_CertSign
  Crl_Sign
]

#9: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 13 AD BF 43 09 BD 82 70   9C 8C D5 4F 31 6E D5 22  ...C...p...O1n."
0010: 98 8A 1B D4                                        ....
]
]
</code>