y0o.de · GNU/Linux Nachrichten u.Ä.

🔒
❌ Über y0o.de
Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Ältere BeiträgeHaupt-Feeds

Grub 2.06 unterstützt LUKS2-Verschlüsselung

10. Juni 2021 um 10:32

Ursprünglich sollte die neue Version von Grub schon im letzten Jahr erscheinen, dafür bietet der Bootloader trotz des kleinen Versionssprungs mehrere interessante Neuerungen. Unter anderem schützt Grub 2.06 vor den zwei BootHole-Attacken und versteht sich mit LUKS2 verschlüsselten Partitionen.

Neu ist auch der Support für SBAT und die Xen Security Module (XSM/FLASK). Standardmäßig deaktiviert ist “os-prober”, das die installierten Betriebssysteme erkennt und automatisch passende Menüeinträge generiert.

Darüber hinaus haben die Grub-Entwickler zahlreiche von einzelnen Distributoren vorgenommene Änderungen zurückportiert. Abschließend unterstützt Grub 2.06 die Compiler GCC und Clang/LLVM jeweils in der Version 10. Der Quellcode von Grub 2.06 ist auf seiner Website verfügbar.

Der Beitrag Grub 2.06 unterstützt LUKS2-Verschlüsselung erschien zuerst auf Linux-Magazin.

GRUB 2.06 endlich mit LUKS2-Unterstützung

10. Juni 2021 um 08:24

Die verspätete Veröffentlichung von GRUB 2.06 bietet neben der Integration wichtiger Sicherheitspatches auch Unterstützung für GCC10, Clang 10 sowie für verschlüsselte LUKS2-Volumes.

Quelle

Verified Boot – Leerstelle unter Linux?

14. Mai 2021 um 18:54
Von: Gerrit

Ein möglichst offenes und ein möglichst vertrauenswürdiges System widersprechen sich manchmal. Besonders deutlich wird dies beim Thema Verified Boot unter Linux.

Linux kennt mit LUKS/cm-crypt eine gute und sichere Verschlüsselungslösung. Man kann ein solchermaßen verschlüsseltes System sogar zusätzlich mit einem Hardware-Token wie z. B. einem YubiKey absichern. Doch woher weiß man beim Hochfahren eines Systems eigentlich, das man ein unverändertes System startet und nicht eine heimlich manipulierte Variante?

Ein sogenannter Verifizierter oder Vertrauenswürdiger Start (Verified / Trusted Boot) ist bei Mobilgeräten schon länger Standard. Der Ansatz ist – stark vereinfacht dargestellt – eine Vertrauenskette vom Bootloader, über die Boot-Partition bis hin zu den verifizierten System-Partitionen. Während des Systemstarts überprüft jede Stufe die Integrität und Sicherheit der nächsten Stufe, bevor sie übergibt. Erkennt das System eine Manipulation, führt es automatisch einen Rollback zur letzten verifizierten Version durch.

Klassische Desktop- oder Notebooksysteme kennen so etwas nicht. Das meist völlig ungesicherte BIOS erlaubt den Start von jedem beliebigen Medium und sofern man dabei nicht den Bootloader versehentlich zerstört, kann man so ziemlich alles mit dem System machen, was man möchte.

Apple hat das Prinzip des Verified Boot bereits vor längerer Zeit auf den Desktop gebracht mit den sogenannten T1/T2 Sicherheitschips. Der T1 brachte die Secure Enclave vom Mobilgerät auf das MacBook bzw. den iMac, der T2 brachte den sichereren Start.

Bei normaler Desktop-/Notebook-Hardware wäre so etwas theoretisch auch möglich. Microsoft hat vor einigen Jahren mit Secure Boot versucht, einige Schritte in diese Richtung zu unternehmen. Aus der ersten Debatte um diese Funktion hat sich leider in der Linux-Community das Gerücht gehalten, dass man Secure Boot immer deaktivieren sollte. Dabei funktionieren professionelle Linux-Distributionen schon lange mit Secure Boot (und alle anderen verwendet man sowieso nicht, wenn einem Sicherheit wichtig ist).

Alle heute verkauften Geräte haben zudem einen sogenannten TPM-Sicherheitschip (verdankt man den Basis-Anforderungen von Microsoft). Die neueste systemd-Version unterstützt nicht nur die Bindung der LUKS-Verschlüsselung an diesen TPM-Chip, sondern SUSE hat auch eine Implementierung von Trusted Boot für GRUB entwickelt (mehr Informationen dazu), die theoretisch mit dem TPM-Chip zusammen arbeitet.

Meiner Meinung nach sind das sinnvolle Schritte in die richtige Richtung. Wie immer stört das natürlich die Frickler und Bastler in der Community, aber wenn man im Bereich Sicherheit am Ball bleiben möchte, kann man diese Entwicklung nicht ignorieren.

Secure Boot ist unter openSUSE schon lange kein Problem mehr, mit der nächsten systemd-Version werde ich mein LUKS-Systemvolume auch an den TPM-Chip binden. Danach folgt dann TrustedGRUB/Trusted Boot aber hier scheint es noch wenige Erfahrungen und folglich auch wenige Bericht zu geben.

Der Artikel Verified Boot – Leerstelle unter Linux? erschien zuerst auf [Mer]Curius

LVM Anleitung - Volume Group umbenennen (Ubuntu/Mint)

29. Oktober 2020 um 15:45

Nachdem ich vor ein paar Tagen auf LVM und einen Update Fehler eingegangen bin, möchte ich heute kurz zeigen, wie eine Volume Group umbenannt werden kann.

Unter Ubuntu/Mint ist das an sich nur ein Befehl, allerdings sollten noch weitere Dateien angepasst werden, da es sonst zu Problemen kommt.

fstab

LVM - Volume Group umbenennen

Informationen zur vorhandenen Volume Group anzeigen

sudo vgdisplay

 

Volume Group umbenennen

sudo vgrename Ubuntu16 ubuntu

  Volume group "Ubuntu16" successfully renamed to "ubuntu"

 

File system table editieren und Name anpassen

sudo  nano /etc/fstab

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

/dev/mapper/ubuntu-root /               ext4    errors=remount-ro 0   1

/dev/mapper/ubuntu-tmp  /tmp            ext4    errors=remount-ro 0   1

/dev/mapper/ubuntu-var  /var            ext4    errors=remount-ro 0   1

 

Initramfs anpassen, ebenfalls hier den neuen Namen einfügen

sudo nano /etc/initramfs-tools/conf.d/resume

 

Danach muss noch der Grand Unified Bootloader GRUB angepasst werden

sudo nano /boot/grub/grub.cfg

 

Ab Ubuntu 18.04 gilt es einen weitereren Eintrag zu editieren

sudo nano /boot/grub/menu.lst

 

Nun muss noch das initial ram filesystem neu gebaut werden

sudo  update-initramfs -u -k all

 

Mögliche Fehlermeldung

update-initramfs: Generating /boot/initrd.img-5.4.0-52-generic

cryptsetup: ERROR: Couldn't resolve device

Solltet ihr cryptsetup nicht verwenden, dann könnt ihr diesen Fehler ignorieren oder auch gleich deinstallieren

sudo apt-get remove cryptsetup

Alles auf einmal

Hier nochmal alle Schritte zusammengestellt. Der Einfachheit halber, können Änderungen mit sed gemacht werden

#!/bin/bash

altevolumegroup="ubuntu16"
neuevolumegroup="ubuntu"

vgrename ${altevolumegroup} ${neuevolumegroup}
sed -i "s/${altevolumegroup}/${neuevolumegroup}/g" /etc/fstab
sed -i "s/${altevolumegroup}/${neuevolumegroup}/g" /boot/grub/grub.cfg
sed -i "s/${altevolumegroup}/${neuevolumegroup}/g" /boot/grub/menu.lst
sed -i "s/${altevolumegroup}/${neuevolumegroup}/g" /etc/initramfs-tools/conf.d/resume
update-initramfs -c -k all

Anstatt des Namens kann übrigens auch die UUID genommen werden. Allerdings solltet ihr das Script dann so nicht verwenden.

vgrename Zvlifi-Ep3t-e0Ng-U44h-o0ye-KHu1-nl7Ns4 ubuntu

 

Schwierige Reparatur von BootHole

31. Juli 2020 um 08:59

Die Behebung der Sicherheitslücke BootHole erweist sich als schwierig. Bei vielen Distributionen verweigern Rechner nach dem Update den Start.

BootHole bricht Secure Boot

30. Juli 2020 um 10:48

Anders als der Name BootHole suggeriert, stecken im Linux-Boot-Manager Grub2, aber auch im Linux-Kernel, gleich mehrere Schwachstellen. Die erlauben es, Secure Boot unter Linux zu umgehen und potenziell bösartige Bootloader oder Bootkits zu laden.

Angreifer, die Rootzugang zum Bootloader eines Systems haben, können die Secure-Boot-Mechanismen von Grub2 überwinden und Bootkits oder bösartige Bootloader auf dem Rechner einschleusen, die das Betriebssystem im folgenden nicht entdeckt. Für den Cloud- und Rechenzentrumsbereich sei die Lücke laut Suse weniger gefährlich. Die Lücken wirken sich vor allem in Szenarios aus, in denen Linux-Rechner im öffentlichen Raum zum Einsatz kommen, etwa in Bibliotheken, Schulen, Universitäten, aber auch an Arbeitsplätzen.

Neben Linux-Systemen, die Grub2 verwenden (und das sind fast alle), betrifft BootHole auch indirekt Microsoft, weil das Unternehmen als UEFI Certificate Authority dient. Die Microsoft-CA stellt auch für mehrere Linux-Distributionen die Zertifikate aus, die sicherstellen, dass der von der Hardware geladene Code vertrauenswürdig ist. Dazu prüft und signiert Microsoft den Code von Drittanbietern wie Canonical oder Red Hat, der meist Shim genannt wird.

Nicht nur eine Lücke

Im Bootloader Grub2 hatte Eclypsium zunächst eine schwere Sicherheitslücke entdeckt, die beim Einlesen und Parsen der Grub-Konfiguration (“grub.cfg”) auftritt. Sie erlaubt es, einen Pufferüberlauf auszulösen und so den üblichen Secure-Boot-Verifizierungsprozess zu umgehen. Laut Canonical wurde die Lücke bereits im April 2020 im Responsible-Disclosure-Verfahren veröffentlicht, das den Distributionen Zeit gibt, sich mit Gegenmaßnahmen zu beschäftigen, bevor die Entdecker an die Öffentlichkeit gehen.

Die Entwickler der verschiedenen Linux-Distributionen haben bei dieser Gelegenheit noch einmal die Grub2-Sicherheit generell genauer unter die Lupe genommen und prompt diverse weitere Lücken in Grub2 entdeckt. Und nicht nur das: Auch der Linux-Kernel selbst erlaubt es in bestimmten Fällen, Secure Boot zu umgehen. Sämtliche Probleme listet unter anderem das von Debian veröffentlichte DSA-4735 auf. Dabei ist die Bedrohung nicht theoretisch. Eclypsium nennt mehrere bösartige Bootloader, die bereits im Umlauf sind und zum Teil von Hackergruppen im staatlichen Auftrag stammen. Einige davon sind Ransomware.

Tief verwurzelt

Ein zentrales Problem beim Reparieren dieser Lücken bestehe laut den Debian-Entwicklern darin, dass der Bootmanager ziemlich tief im System verankert ist. Es genügt nicht, neue Versionen des Bootloaders zu signieren und auszurollen. Angreifer könnten einfach weiterhin lokal ältere Versionen des Bootloaders installieren und so die Lücke wieder in Kraft setzen. Die alten Versionen gilt es also auch zu sperren. Dafür sieht UEFI Sperrlisten vor.

Das Aktualisieren solcher UEFI Revocation Lists ist allerdings heikel, weil es bei einigen Secure-Boot-Nutzern Probleme verursachen kann: Wer die Sperrliste installiert, aber weiterhin die alten Grub2-Binaries einsetzt, könnte vor einem nicht-bootbaren System sitzen. Nicht alle Nutzer bekommen es hin, Secure Boot über das UEFI-BIOS zu deaktivieren, die UEFI-Updates einzuspielen und dann das System mit Secure Boot wieder neu zu booten oder alternativ den Rescue-Modus zu verwenden. Und rollt ein unerfahrener Admin ohne zu testen gleich viele Updates aus, kann er eine ganze Armada von Systemen temporär unbenutzbar machen. Das dürfte vor allem auch den IoT-Bereich treffen, in dem Systeme weltweit ohne direkten Zugriff vor sich hin werkeln.

Dennoch will Microsoft ältere und unsichere Binaries auf eine UEFI-Revocation-Liste setzen, so dass sich diese nicht mehr verwenden lassen. Wann das aber passiert, ist laut Debian-Projekt noch unklar. Die Hardwarehersteller werden diese Listen künftig in ihre neue Firmware für neue Geräte integrieren. Linux-Distributionen liefern die Listen vermutlich über Updates aus. Die betreffen aber oft nur neuere Versionen einer Distribution. Der Grund: Debian 9 hat Secure Boot zum Beispiel noch nicht unterstützt, braucht also auch keine Updates (ist damit aber auch per se anfällig für bösartigen Bootcode).

Patches

Wie die Patches und die Strategien für die einzelnen Distributionen aussehen, unterscheidet sich je nach Anbieter. Positiv ist, dass die großen Linux-Anbieter sich offenbar gut koordinieren und ihre jeweiligen Umgehungsstrategien nahezu zeitgleich veröffentlicht haben. Hier geht es zu den jeweiligen Fehlerbeschreibungen von Debian, Ubuntu, Suse und Red Hat. Auch Microsoft liefert liefert als Aussteller der Zertifikate eine Beschreibung, um die Revocation-Liste manuell zu reparieren. Gewöhnliche Linux-Anwender sollten aber einfach die Updates für ihre Systeme einspielen.

Der Beitrag BootHole bricht Secure Boot erschien zuerst auf Linux-Magazin.

Es ist ein Loch im Schuh…

30. Juli 2020 um 09:59

BootHole ist eine Verwundbarkeit von signierten Paketen des GRUB2-Bootmanagers. Schadcode im Bootprozess kann aber nur mit Root-Rechten platziert werden.

BootHole – CVE-2020-10713 – bitte aktualisieren – GRUB2 betroffen!

30. Juli 2020 um 09:36
Von: jdo

Mehrere große Linux-Distributoren haben gemeinsam Updates ausgegeben, um damit eine Security-Lücke mit Namen BootHole zu adressieren. Das Problem ist bei Eclypsium beschrieben, die es auch als BootHole bezeichnet habe. Die Sicherheitslücke wurde als CVE-2020-10713 gemeldet. Angreifer brauchen administrative Rechte, um die Sicherheitslücke ausnutzen zu können. Die Entdecker der des Sicherheitsproblems haben dabei mit den Linux-Distributoren, Computer-Herstellern und anderen Einrichtungen in der Branche zusammengearbeitet, um die Sicherheitslücke verantwortungsvoll zu veröffentlichen. Canonical schreibt zum Beispiel, dass sie bereits im April 2020 über […]

Der Beitrag BootHole – CVE-2020-10713 – bitte aktualisieren – GRUB2 betroffen! ist von bitblokes.de.

Shutdown, Reboot und Firmware Setup Eintrag zu GRUB hinzufügen

10. Oktober 2019 um 06:30

Man kann unter anderem auch vom GRUB Menü aus ins Firmware Setup booten oder auch das System neustarten oder herunterfahren. Diese Shutdown, Reboot und Firmware Setup Einträge lassen sich schnell und einfach zu GRUB...

Super Grub2 Disk aktualisiert Grub und verbessert UEFI-Support

28. August 2019 um 11:49

Mit dem Live-System Super Grub2 Disk können Anwender ihre installierten Systeme auch dann booten, wenn der Boot-Manager defekt ist. Die Macher haben jetzt eine neue stabile Version veröffentlicht, die auf Grub 2.04 basiert.

Super Grub2 Disk 2.04 erhält somit nebenbei ein paar neue Features. So unterstützt das Live-System jetzt das F2FS-Dateisystem sowie UEFI Secure Boot via Shim. Zudem kann die Super Grub2 Disk besser mit dem Dateisystem Btrfs umgehen: Verbesserungen gab es sowohl beim Umgang mit der Zstd-Kompression als auch in den RAID-Modi 5 und 6. Abschließend unterstützt die Super Grub2 Disk 2.04s1 UEFI TPM 1.2/2.0 und Xen PVH.

Der Beitrag Super Grub2 Disk aktualisiert Grub und verbessert UEFI-Support erschien zuerst auf Linux-Magazin.

Neue Version der Super Grub2 Disk aktualisiert Grub und verbessert UEFI-Support

27. August 2019 um 18:08

Mit dem Live-System Super Grub2 Disk können Anwender ihre installierten Systeme auch dann booten, wenn der Boot-Manager defekt ist. Die Macher haben jetzt eine neue stabile Version veröffentlicht, die auf Grub 2.04 basiert. Sie erhält somit nebenbei ein paar neue Features. So unterstützt das Live-System jetzt das F2FS-Dateisystem sowie UEFI Secure Boot via Shim. Zudem […]

Der Beitrag Neue Version der Super Grub2 Disk aktualisiert Grub und verbessert UEFI-Support erschien zuerst auf LinuxCommunity.

Arch Linux: grub-mkconfig hängt sich auf

14. Februar 2019 um 06:30

Ich musste mal wieder meinen PC komplett neuinstallieren. Eigentlich hätte ich nur Windoof 10 Windows 10 neuinstallieren müssen, aber Windows 10 hat, warum auch immer, auch meine SSD mit Arch Linux formatiert. Aber um Windows...

❌