Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe 
allgemeine Kategorie => Installation & Einrichtung => Thema von: Sebastian am 27. Dezember 2022, 21:53:44
Titel: systemd-boot
Beitrag von: Sebastian am 27. Dezember 2022, 21:53:44
Hallo Suletuxe,

ich mache zurzeit meine ersten Erfahrungen mit systemd-boot als Bootloader anstelle von grub. Nicht an einem produktiven System, sondern einfach so zum Ausprobieren.

Nachdem man sich da erst einmal so ein wenig eingefunden hat, muss ich sagen wird systemd-boot in Zukunft mein Favorisierter Bootloader für Systeme die mit systemd laufen, und keine Verschlüsselung verwenden. Mit anderen Worten keine mächtigen Funktionen, die sonst nur grub, beherrscht brauchen.

An meisten gefällt mir bei systemd-boot das sich das "logischerweise" mit den restlichen systemd Tools harmoniert. Somit gibt es auch Tools, um den Bootloader zu installieren, updaten und Infos zu Konfigurationen anzuzeigen, dabei werden die Ausgaben systemd typisch gut lesbar formatiert, teilweise in Farbe/Symbolen und Unterstreichungen. Es lassen sich auf jeden fall die Ausgaben sehr angenehm lesen.

Zudem lassen sich bei Verwendung von mehreren unterstützen Betriebssystem gleich für den nächsten Neustart das Betriebssystem mit angeben, das man gerne starten möchte, falls man das Bootmenü direkt überspringen möchte. (Choosing next boot (https://wiki.archlinux.org/title/Systemd-boot#Choosing_next_boot))

Die Hauptunterschiede, die es gibt, für diejenigen, die sich hauptsächlich mit grub auskennen sind folgende:


  • Unterstützt nur EFI
  • Der übliche standardisierte Mount Point für die EFI Partition ist nicht mehr /boot/efi sondern nur noch /efi. /boot/efi funktioniert zwar auch noch wird aber üblicher weiße so nicht gemacht.
  • /boot ist damit leer. Denn auch die Kernals und Initramfs befinden sich auf der ESP (EFI System Partition)
  • Für jedes installierte Betriebssystem gibt es ein Ordner in /efi der aus der MACHINE-ID(5) (https://man.archlinux.org/man/machine-id.5) besteht. In diesem befindet sich dann die verschiedenen Kernels Initramfs für das jeweilige System.
  • Die Konfiguration für die verschiedenen Bootmenü Eintrage wiederum findet man unter /efi/loader/entries/Name-des-Booteintrags.conf. Dort kann man dann auch Kernel Parameter hinzufügen zum Eintrag etc. (Adding loaders (https://wiki.archlinux.org/title/Systemd-boot#Adding_loaders))
  • EOS hat zum automatischen Generieren dieser Konfigs wieder ein Script erstellt das diese zusammen mit einem Pacman Hook bei einem Kernal/systemd Update automatisch vornimmt (reinstall-kernels). Siehe auch: systemd-boot (https://discovery.endeavouros.com/installation/systemd-boot/2022/12/)


    • Bei dem Script reinstall-kernels gibt es eine Sache noch zu beachten:
    Zitat:
    Generally speaking, kernel-install takes the running kernel options from /proc/cmdline unless you have specific settings in /etc/kernel/cmdline. The latter will always take precedence. So that means, by default, if you make a change to the running options or change the entry file and reboot, those changes will automatically get picked up.


    Das ist wichtig zu wissen, falls man sein System in einem chroot bearbeiten will, weil man z.B. nicht mehr davon booten kann. Das Script holt sich die Kernel Parameters von /proc/cmdline, wenn es keine /etc/kernel/cmdline Datei finden kann. Und die Bootparameter im chroot aus der Live ISO sind natürlich die verkehrten, sodass das Skript falsche Booteinträge generiert.

    Bei einer Neuinstallation schreibt der Installer passende Kernel Boot Parameter in die /etc/kernel/cmdline falls man selbst auf Systemd-boot umsteigen möchte dann sollte man daran, denken diese Datei anzulegen. Zudem ist das dann auch der beste Ort wo man seine eigenen Kernel Boot Parameter hinzufügen kann, da diese dann von den Generierungs-Skript mit übernommen werden. (siehe auch Convert to systemd-boot (https://forum.endeavouros.com/t/tutorial-convert-to-systemd-boot/13290][Tutorial))
Titel: Re:systemd-boot
Beitrag von: Andreas am 28. Dezember 2022, 08:52:51
Hallo Sebastian,

warum verwendest Du für deine verschlüsselten Systeme nicht ein Verfahren, bei dem /boot auf einer eigenen Partition liegt? Im Ordner /boot liegen meiner Ansicht nach keine "kritischen" Informationen, und auf diese Weise kannst Du den kompletten Rest "vollverschlüsseln". Das geht dann auch mit systemd-boot. Du könntest es sogar so machen dass /boot auf einem speziellen USB-Stick liegt und in dessen mbr auch der Bootsektor liegt. Wenn Du dann noch per GPG-Schlüssel entschlüsselst musst Du noch nicht mal ein Passwort eingeben - es reicht, wenn nur Du Zugriff auf den Stick hast.

Ich habe mich (war noch zu Ubuntu-Zeiten) auch mal mit Verschlüsselung mit all ihren Facetten beschäftigt und damit experimentiert. Mir waren die Nachteile einer Vollverschlüsselung (die Wahrscheinlichkeit eines kompletten Datenverlustes z.B. bei einem Festplattenproblem steigt exponentiell, es wird zusätzlich Rechenleistung dauerhaft im Hintergrund "abgezwackt") zu schwerwiegend so dass ich nur bestimmte Teile meines /home-Verzeichnisses verschlüssele. Das sind dann auch alles reine Dateien, keine Konfigurationen etc. Passwörter verwalte ich mittels kwallet - das ist sowieso verschlüsselt. Ich nutze dafür "Veracrypt". Die damit erstellten Container lassen sich auch leicht in einen Backuplauf einbinden (gaaaanz wichtig). Backups sind sowieso der beste Freund eines jeden Computernutzers (sollten sie auf jeden Fall sein). Ohne einfache Möglichkeit von Backups ist ein System in meinen Augen alltagsuntauglich...

LG
Andreas
Titel: Re:systemd-boot
Beitrag von: Sebastian am 28. Dezember 2022, 12:45:03
Hallo Andreas,

Mein Setup ist momentan folgendes:


  • ESP (EFI System Partition) unverschlüsselt (Etwas muss ja von UEFI gelesen werden können). Darauf befindet sich nur der Bootloader grub nichts weiter.
  • Eine große LUKS Partition, die von grub geöffnet wird. Dort drin befindet sich dann zwei LVs (Logical Volumes) eine für / und die anderen für /home
  • Auf beiden Lvs verwende ich ext4


    • Geplant ist vielleicht irgendwann die LVs mit einem großen btrfs Dateisystem zu ersetzten und in dem Dateisystem dann zwischen / und/home zu unterscheiden. Nur dafür müsste ich noch die Zeit finden mich mehr mit btrfs zu beschäftigen.

    Warum ich jetzt die /boot Partition nicht unverschlüsselt lasse liegt daran, weil ich nicht genau weiß welche Angriffsfaktoren man aus dem ungeschützten initramfs und Kernel ableiten könnte. Da hole ich lieber die Keule raus und schütze diese Dinge gleich mit (macht keinen großen mehr aufwand). Einziger Nachteil ist das Grub ca. 20 Sekunden zum öffnen der Luks Partition brauch, da in diesem Boot Stadium noch nicht Encryption Funktionen der CPU genutzt werden können. Auslagern der /boot Partition auf ein externes Medium möchte ich nicht, weil ich mir keine Sorgen machen möchte, dass bei Verlust bzw. vergessen den USB-Stick mitzunehmen ich nicht an meine Daten komme. Ok, gegen den Verlust hilft ein Backup, gedanklich habe ich aber gerne alles, was ich brauche in einem Gerät. Und nutze damit nur ein Faktor zu Authentifizierung (Wissen, das Passwort). Was für meinen Thread Model (https://www.privacyguides.org/basics/threat-modeling/) (Schutz vor Diebstahl/Verlust und unerkannter Manipulation) ausreichend ist. Würde ich ein externes Medium verwenden, so würde ich, wie ich mich kenne dann wahrscheinlich aus Bequemlichkeit denn Stick einfach mit in die Notebooktasche legen, und dieser würde dann gleich mit gestohlen, was in meinen Fall dann die Sicherheit sogar noch verringert.

    Somit habe ich zwei Schutzziele der schwache Integrität (https://www.kryptowissen.de/schutzziele.php]CIA[/url] (Hat nichts mit dem Geheimdienst zu tun),[url=https://www.kryptowissen.de/schutzziele.php#vertraulichkeit]Vertraulichkeit[/url] und die [url=https://www.kryptowissen.de/schutzziele.php#integritaet) abgedeckt.

    Das einzige, was mir in dieser Trust Kette noch fehlt, ist der Schutz des Bootloaders auf der unverschlüsselten ESP. Da ist für die Zukunft geplant diesen zu Signieren und mit meinen eigenen Keys mithilfe von SecureBoot abzusichern, damit eine Manipulation des Bootloaders auch erkannt werden kann. Dafür habe ich mir leider noch nicht die Zeit genommen, mich damit mehr zu beschäftigen.

    Also im Grunde verschlüssele ich /boot gleich mit, weil ich irgendwann vorhabe, die Trust Kette bis zum Bootloader zu sichern. Das aber auch nur aus dem Interesse her. Für mich persönlich reicht das Vertrauen bis zum geschützten Kernel, Initramfs.

    Was die Performance angeht, kann ich keinen merklichen Unterschied im Alltag feststellen, der durch die Verschlüsselung im Hintergrund anfällt (Bis auf die 20 Sekunden die grub anfänglich brauch). Das liegt wahrscheinlich auch daran, dass moderne CPUs für diesen Anwendungsfall alle schon Crypto Eigenschaften mitbringen. Ich hatte auch noch ein Gerät gehabt, wo die CPU so etwas nicht hatte. Dort hat man die Verschlüsselung beim Arbeiten dann doch richtig gemerkt. Dort wurde dann alles Software mäßig emuliert.

    Was die Angst vor Datenverlust auf einem verschlüsselten Datenträger anbelangt, dagegen hilft wie auch bei unverschlüsselten Datenträgern nur Backups. Ich handhabe das bei mir so:


    • Backup existieren bei mir nur auf lokalen verschlüsselten Datenträgern. Nicht die Cloud, Cloud ist ein anderer Name für ich speichere meine Daten auf einen fremden Rechner, der nicht unter meiner Kontrolle steht. Wenn mir der Zugang zu einem Cloud-Anbieter verwehrt wird hilft mir auch nicht das die Daten vorher verschlüsselt waren.
    • Von den externen Backup-Datenträgern habe ich zusätzlich ein CRYPTSETUP-LUKSHEADERBACKUP(8) (https://man.archlinux.org/man/cryptsetup-luksHeaderBackup.8.en) für den Fall eines Hardwaredefektes, dass der Header Bereich beschädigt wird und eine Entschlüsselung somit nicht mehr möglich wäre.
    • Tritt ein Hardwaredefekt an einer anderen Stelle auf, ist es im Grund egal, ob die Daten verschlüsselt oder nicht verschlüsselt waren, in beiden Fällen sind die Daten defekt. Bzw. sollte der Datenträger verschlüsselt gewesen sein, so muss man ihn einfach wie gewohnt erst öffnen und die Reparaturmaßnahmen am geöffneten Mount Punkt vornehmen (fsck und andere Rettungstools) alles verhähllt sich dann so weiter als wäre der Datenträger nicht verschlüsselt.
    • Bzw. das beste vorgehen bei einem Defekten Datenträger ob verschlüsselt oder nicht ist, erst mal mit DDRESCUE(1) (https://man.archlinux.org/man/extra/ddrescue/ddrescue.1.en) so viele Daten wie möglich von Datenträger zu kratzen und in ein Image zu speichern. Und spätere Datenrettungsversuche am Image dann durchzuführen. Das musste ich tatsächlich so in dieser Form schon mal bei jemanden machen, da die Festplatte anfing eine Grätsche zu machen. Da war ich selbst erstaunt wie viele Daten man von der Festplatte noch retten konnte, die sporadisch immer wieder ausfälle, hatte. Und normal ga nicht mehr ansprechbar war bzw. sich auch nicht mehr mounten lies.


      • Gedanklich habe ich aber natürlich auch schon mit anderen Entschlüsselungsmethoden gespielt. :)



      • So was wie RAW Daten von einem nicht benutzten Bereich eines USB-Sticks auszulesen und als Key-file für eine Luks Partition zu verwenden. Damit man praktisch nicht einmal weiß, dass auf dem USB-Stick ein Key-file liegt (also nach dem Prinzip der Steganographie (https://de.wikipedia.org/wiki/Steganographie)).
      • Oder den Key in einem TPM abzulegen. Nur hierbei würde beim defekt des TPMs ich mich wirklich ausschließen. Bzw. es bringt mir hier nichts, wenn das komplette Notebook samt TPM gestohlen wird. Hier würde ich praktisch nur verhindern, dass die Festplatte an keinen anderen Rechner gelesen werden kann. Schützt mich also nicht vor Diebstahl



        • Ich hoffe das irgendwann grub in den Arch Repos so langsam auch mal LUKS 2 Partitionen unterstützt. Denn Luks 1, hält so langsam mit den modernen GPUs nicht mehr mit. Sonst muss man seine Passphrase noch weiter verlängern, sodass es bald kein Spaß mehr macht so viel zu tippen. :)

        LG
        Sebastian
Titel: Re:systemd-boot
Beitrag von: Andreas am 28. Dezember 2022, 14:15:01
Ich verwende Linux nun schon seit dem Jahr 2000 (angefangen mit SuSE).

Relativ schnell (nach 3 Jahren) kämpfte ich mit einem (schon immer) mangels Know-How fehlkonfigurierten RAID1 und einer defekten Platte (selbstverständlich der auf der die Daten waren) und musste ein neues System aus den Backups aufsetzen.

Ich hatte in der gesamten Zeit kein einziges Problem mit einem "lokalen Angriff" (also jemand der vor meinem Gerät selbst gesessen hat und Zugriff erlangt hat). Auch ist noch nie ein Gerät in fremde Hände gelangt (es wurde gestohlen oder ich habe es irgendwo vergessen).

Was aber millionenfach in der Zeit gewesen ist waren Angriffsversuche von außen. Betroffen waren natürlich meine Webserver und mein Server zu Hause (beide sind über das Internet zu erreichen). Andere Geräte sind hinter Firewalls (also nicht von außen zu erreichen). Ich lerne ständig dazu wie man sein System gegen solche Angriffe weiter verbessert. Einen gelungenen Angriff hatte ich noch niemals.

Sicher: das Risiko eines Einbruchs mit Diebstahl eines meiner Linux-Geräte ist nicht NULL. Ich schätze es aber ähnlich hoch ein wie an zwei aufeinanderfolgenden Wochen jeweils sechs richtige im Lotto. Jedes andere "gefährliche Szenario" ist wahrscheinlicher. Deswegen schütze ich lediglich wichtiges Know-How (FPGA- oder anderer Quellcode, Geschäftsdaten) in einem verschlüsselten Container. Ansonsten ist mir der Nutzfaktor einer Komplettverschlüsselung gegenüber den Nachteilen zu gering. Klar: das muss jeder für sich selbst entscheiden. Ich kann mit meiner Entscheidung auf jeden Fall schlafen wie ein Murmeltier - auch bei dem Gedanken dass mir morgen evtl. ein Gerät entwendet wird...

LG
Andreas
Titel: Re:systemd-boot
Beitrag von: Sebastian am 28. Dezember 2022, 15:01:36
Jeder hat halt ein anderes Sicherheitsbedürfnis, das je nach Lebenslage und persönlicher Einstellung auch normal und gut so ist. Mir gibt es halt ein beruhigendes Gefühl, dass ich mein Notebook auch mal unbeaufsichtigt liegen lassen kann, ohne dass meine Daten missbraucht werden könnten. Besonders als ich eine Festplatte wegen Defekts einmal reklamieren musste, konnte ich guten Gewissens einfach diese zurückschicken.

Remote Angriffe sind natürlich noch einmal ein ganz anderes Thema, da gebe ich dir aber recht, die Wahrscheinlichkeit dort Opfer eines Angriffes zu werden ist um einiges größer als bei einem lokalen Angriff. Ich finde beides wichtig, natürlich sollte man sich auch dagegen schützen, was ich auch tue. Ich habe keine Services am Laufen, die von Außen erreichbar sind. Alle Verbindungen gehen von meinem Gerät aus, da sehe ich bei mir das größte Einfallstor den Webbrowser. Deswegen nutze ich diesen auch mit unterschiedlichen Browser Sessions, um die Domains voneinander abzukapseln, um XSS Attacken zu erschwären. Auch Javascript wird bei mir nur für Vertrauenswürde Domains aktiviert und ist beim Surfen bei mir nicht der Standard. Das macht das Surfen zwar um einiges unangenehmer, weil nicht sofort alles funktioniert. Aber nach einer gewissen Einrichtungszeit. Stellt sich der Mehraufwand ein, da man feststellt, dass man meistens sowieso immer auf den gleichen Seiten unterwegs ist. Um ab und zu aus der Bubble herauszuschauen, wird dann zum Tor Browser gegriffen.

Persönliche Daten, Dokumente etc. schütze ich in dem Sinne auf meinen Backup-Platten genauso wie du in einem verschlüsselten Container. Nur dass sich dieser über die ganze Platte erstreckt ;D

Edit:
Zitat:
Ich hatte in der gesamten Zeit kein einziges Problem mit einem "lokalen Angriff" (also jemand der vor meinem Gerät selbst gesessen hat und Zugriff erlangt hat). Auch ist noch nie ein Gerät in fremde Hände gelangt (es wurde gestohlen oder ich habe es irgendwo vergessen).


Im privaten Umfeld wird das wahrscheinlich auch sehr gut hinkommen. Aber im kommerziellen Umfeld ist das schon wahrscheinlicher. Die Versuchung war schon immer recht hoch im Unternehmen einen USB-Stick zu booten, um sich Adminrechte zu verschaffen, weil Festplatte, UEFI usw. natürlich nicht geschützt waren. Gedanklich habe ich das schon fast als Einladung gesehen, wenn man den Login nur auf Betriebssystem Ebene sperrt (Nach dem Motto, der Schutz ist so gering, dass man das nicht als gewollte Sicherheitsmaßnahme sehen kann, weil nicht zu Ende gedacht).

Naja nach einem Sicherheitsvorfall hat sich die lange bei uns zum Glück gebessert, sodass es diese Möglichkeit nicht mehr gibt.

LG
Sebastian


Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.