forum.opsi.org

Verfasst: **03 Feb 2022, 15:01**

Ok, danke.

Wir machen ein Testgerät inkl. Dockingstation und allen Zubehör versandtbereit...

m.radtke hat geschrieben: ↑03 Feb 2022, 14:39 Hi

shimx64.efi.signed und grubx64.efi

Gruß
Mathias

Verfasst: **04 Feb 2022, 10:32**

Alles klar.

Werde mir das Gerät mal ansehen sobald es da ist

Habe heute in einer VM mit Secureboot ein Update der dbx gemacht. Diese beinhaltet die Hashes von "verboteten" Dateien.

Code: Alles auswählen

shimx64.efi.signed
root@vmex16204:~# mokutil --dbx | grep 424c636253b4efa0c69f91505ee16d7079956b8ede4524ffce211a1b037ff692
root@vmex16204:~# 
grubx64.efi
root@vmex16204:~# mokutil --dbx | grep 6019c1882361076daff7d4302805aacea726c01af956887ed945f1daa09f23c8
root@vmex16204:~#

Das dbxupdate habe ich direkt von https://uefi.org/revocationlistfile geladen.
In der dbx sind 261 Hashsummen vorhanden

Gruß
Mathias

Verfasst: **04 Feb 2022, 11:27**

Moin,

danke, bin erstmal im Urlaub, also ist genügend Zeit, um damit testen zu können.

Ich interpretiere es so: Also ist bspw. der grubx64.efi schon mal kein potenzieller Kandidat, weshalb es beim L15 Gen. 2 nicht mit Secureboot bei OPSI funktioniert?!?

m.radtke hat geschrieben: ↑04 Feb 2022, 10:32 Alles klar.

Werde mir das Gerät mal ansehen sobald es da ist

Habe heute in einer VM mit Secureboot ein Update der dbx gemacht. Diese beinhaltet die Hashes von "verboteten" Dateien.
Code: Alles auswählen
shimx64.efi.signed
root@vmex16204:~# mokutil --dbx | grep 424c636253b4efa0c69f91505ee16d7079956b8ede4524ffce211a1b037ff692
root@vmex16204:~# 
grubx64.efi
root@vmex16204:~# mokutil --dbx | grep 6019c1882361076daff7d4302805aacea726c01af956887ed945f1daa09f23c8
root@vmex16204:~# 
Das dbxupdate habe ich direkt von https://uefi.org/revocationlistfile geladen.
In der dbx sind 261 Hashsummen vorhanden

Gruß
Mathias

Verfasst: **05 Sep 2022, 16:21**

Guten Tag zusammen,

wir haben aktuell neue Dell Hardware bekommen. Precision 3660-Tower mit aktiviertem Secure Boot.
Leider sind wir noch nicht so firm mit Secure Boot und setzen es zum ersten Mal ein.

Die OPSI Konfiguration zu Secure Boot sind wir durchgegangen und die sieht soweit gut aus. Unsere Workstations bieten die Secure Boot Option "deployed mode" und "audit" an. Audit ist lediglich die Prüfung ohne Abbruch bei fehlender Signatur und bringt uns ganz normal durch die Installation.

Sobald wir den Deployed Mode auswählen, fängt er an die Verbindung aufzubauen und läd noch die shimx64 herunter. Ob er damit fertig wird, sehe ich nicht, allerdings kommt definitiv kein "grubx64.efi"

"audit Mode"

Code: Alles auswählen

Sep  5 15:32:34 opsi-wgt in.tftpd[1744696]: RRQ from 192.168.20.158 filename linux/pxelinux.cfg/shimx64.efi.signed
Sep  5 15:32:34 opsi-wgt in.tftpd[1744696]: tftp: client does not accept options
Sep  5 15:32:34 opsi-wgt in.tftpd[1744697]: RRQ from 192.168.20.158 filename linux/pxelinux.cfg/shimx64.efi.signed
Sep  5 15:32:34 opsi-wgt in.tftpd[1744700]: RRQ from 192.168.20.158 filename linux/pxelinux.cfg/grubx64.efi
Sep  5 15:32:37 opsi-wgt in.tftpd[1744702]: RRQ from 192.168.20.158 filename /grub/grub.cfg-01-00-XXXXXXXXXXX
Sep  5 15:32:37 opsi-wgt in.tftpd[1744703]: RRQ from 192.168.20.158 filename /grub/grub.cfg-C0A8149E
Sep  5 15:32:37 opsi-wgt in.tftpd[1744704]: RRQ from 192.168.20.158 filename /grub/grub.cfg-C0A8149
Sep  5 15:32:37 opsi-wgt in.tftpd[1744705]: RRQ from 192.168.20.158 filename /grub/grub.cfg-C0A814
Sep  5 15:32:37 opsi-wgt in.tftpd[1744706]: RRQ from 192.168.20.158 filename /grub/grub.cfg-C0A81
Sep  5 15:32:37 opsi-wgt in.tftpd[1744707]: RRQ from 192.168.20.158 filename /grub/grub.cfg-C0A8
Sep  5 15:32:37 opsi-wgt in.tftpd[1744708]: RRQ from 192.168.20.158 filename /grub/grub.cfg-C0A
Sep  5 15:32:37 opsi-wgt in.tftpd[1744709]: RRQ from 192.168.20.158 filename /grub/grub.cfg-C0
Sep  5 15:32:37 opsi-wgt in.tftpd[1744710]: RRQ from 192.168.20.158 filename /grub/grub.cfg-C
Sep  5 15:32:37 opsi-wgt in.tftpd[1744711]: RRQ from 192.168.20.158 filename /grub/x86_64-efi/command.lst
Sep  5 15:32:37 opsi-wgt in.tftpd[1744712]: RRQ from 192.168.20.158 filename /grub/x86_64-efi/fs.lst
Sep  5 15:32:37 opsi-wgt in.tftpd[1744713]: RRQ from 192.168.20.158 filename /grub/x86_64-efi/crypto.lst
Sep  5 15:32:37 opsi-wgt in.tftpd[1744714]: RRQ from 192.168.20.158 filename /grub/x86_64-efi/terminal.lst
Sep  5 15:32:37 opsi-wgt in.tftpd[1744715]: RRQ from 192.168.20.158 filename /grub/grub.cfg

"Deployed Mode" endet wie besprochen direkt so und macht nichts mehr. Auf dem Client kommt dann die Meldung: "operating system loader signature found in secure boot exclusion database (dbx)"

Code: Alles auswählen

Sep  5 15:28:51 opsi-wgt in.tftpd[1744351]: RRQ from 192.168.20.158 filename linux/pxelinux.cfg/shimx64.efi.signed
Sep  5 15:28:51 opsi-wgt in.tftpd[1744351]: tftp: client does not accept options
Sep  5 15:28:51 opsi-wgt in.tftpd[1744352]: RRQ from 192.168.20.158 filename linux/pxelinux.cfg/shimx64.efi.signed

Also irgendwie sagt die Meldung ja auch eindeutig, dass dieses BS gesperrt wäre?!

Könnt ihr uns kurz helfen, wo wir als nächstes schauen sollen bzw was zu prüfen wäre?
Neueste BIOS Firmware ist drauf.
Neueste OPSI Pakete sind installiert.

Herzlichen Dank vorab!
Mit freundlichen Grüßen,
Valentino

Verfasst: **05 Sep 2022, 20:35**

Hi

probier doch mal das bootimage aus experimental. Das hat ne neue Shim die frisch von Microsoft kommt.

Gruß
Mathias

forum.opsi.org

Secureboot UEFI Default Lenovo L15 Gen. 2 funktioniert nicht

Re: Secureboot UEFI Default Lenovo L15 Gen. 2 funktioniert nicht

Re: Secureboot UEFI Default Lenovo L15 Gen. 2 funktioniert nicht

Re: Secureboot UEFI Default Lenovo L15 Gen. 2 funktioniert nicht

Re: Secureboot UEFI Default Lenovo L15 Gen. 2 funktioniert nicht

Re: Secureboot UEFI Default Lenovo L15 Gen. 2 funktioniert nicht