Automatisches Entsperren des Root-LUKS-Containers nach einem Hot-Boot

Warum verschlüsseln Menschen im Allgemeinen Laufwerke ihrer PCs und manchmal auch Server? Es ist klar, dass niemand Fotos seiner Lieblingskatzen von der Festplatte gestohlen hat! Das ist nur Pech: Bei einem verschlüsselten Laufwerk müssen Sie bei jedem Start eine Schlüsselphrase über die Tastatur eingeben. Das ist lang und langweilig. Um es so zu entfernen, dass es zumindest manchmal nicht notwendig wäre, es zu rekrutieren. Ja, damit die Bedeutung der Verschlüsselung nicht verloren geht.

Nun, vollständig entfernen wird es nicht funktionieren. Sie können stattdessen eine Schlüsseldatei auf einem USB-Flash-Laufwerk erstellen, und es funktioniert auch. Und ohne Flash-Laufwerk (und ohne zweiten Computer im Netzwerk) ist das möglich? Wenn Sie Glück mit dem BIOS haben, können Sie fast! Unter dem Schnitt finden Sie eine Anleitung zum Konfigurieren der Festplattenverschlüsselung über LUKS mit den folgenden Eigenschaften:

1. Die Passphrase oder Schlüsseldatei wird beim Ausschalten des Computers nirgendwo in offener Form (oder in der Form, die dem Öffnen entspricht) gespeichert.
2. Wenn Sie Ihren Computer zum ersten Mal einschalten, müssen Sie eine Passphrase eingeben.
3. Bei nachfolgenden Neustarts (vor dem Herunterfahren) ist keine Passphrase erforderlich.

Die Anweisungen wurden unter CentOS 7.6, Ubuntu 19.04 und openSUSE Leap 15.1 in virtuellen Maschinen und auf realer Hardware (Desktop, Laptop und zwei Server) getestet. Sie sollten auf anderen Distributionen funktionieren, die eine funktionierende Version von Dracut haben.

Und ja, in guter Weise hätte dies im Hub "Anormale Systemadministration" enden sollen, aber es gibt keinen solchen Hub.

Ich schlage vor, einen separaten Steckplatz im LUKS-Container zu verwenden und den Schlüssel dazu zu speichern ... im RAM!

Das BIOS auf den meisten Motherboards bereinigt den Speicher beim Neustart nicht oder Sie können ihn so konfigurieren, dass er nicht bereinigt wird (bekannte Ausnahme: "Intel Corporation S1200SP / S1200SP, BIOS S1200SP.86B.03.01.0042.013020190050 30.01.2019"). Daher können Sie den Schlüssel dort speichern. Wenn das Gerät ausgeschaltet wird, wird der Inhalt des RAM selbst nach einer Weile zusammen mit einer ungeschützten Kopie des Schlüssels gelöscht.

Also lass uns gehen.

Schritt eins: Installieren Sie das System auf einer mit LUKS verschlüsselten Festplatte

In diesem Fall sollte die in /boot gemountete Festplattenpartition (z. B. /dev/sda1 ) unverschlüsselt bleiben und die andere Partition, auf der alles andere (z. B. /dev/sda2 ) verschlüsselt werden soll. Das Dateisystem auf der verschlüsselten Partition kann ein beliebiges sein. Sie können auch LVM verwenden, sodass sich das Root-Dateisystem, das Swap-Volume und alles andere außer /boot im selben Container befinden. Dies entspricht der Standardfestplattenpartitionierung in CentOS 7 und Debian bei Auswahl der Verschlüsselungsoption. SUSE macht alles anders (verschlüsselt /boot ) und erfordert daher eine manuelle Partitionierung der Festplatte.

Das Ergebnis sollte ungefähr so ​​aussehen:

 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 10G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 9G 0 part └─luks-d07a97d7-3258-408c-a17c-e2fb56701c69 253:0 0 9G 0 crypt ├─centos_centos--encrypt2-root 253:1 0 8G 0 lvm / └─centos_centos--encrypt2-swap 253:2 0 1G 0 lvm [SWAP] 

Bei Verwendung von UEFI wird es auch eine EFI-Systempartition geben.

Für Debian- und Ubuntu-Benutzer: Ersetzen Sie das Paket initramfs-tools durch dracut .

 # apt install --no-install-recommends dracut 

initramfs-tools implementiert in unserem Fall eine falsche Logik, die auf verschlüsselte Abschnitte mit einer Schlüsseldatei angewendet wird. Solche Abschnitte werden entweder vollständig ignoriert oder der Inhalt der Schlüsseldatei wird im Klartext in initramfs (d. H. Als Ergebnis auf die Festplatte) kopiert, was wir nicht benötigen.

Schritt 2: Erstellen Sie eine Schlüsseldatei, mit der das Laufwerk nach einem Hot-Neustart automatisch entsperrt wird

128 zufällige Bits reichen für uns aus, d.h. 16 Bytes. Die Datei wird auf einer verschlüsselten Festplatte gespeichert, sodass niemand, der den Verschlüsselungsschlüssel nicht kennt und keinen Root-Zugriff auf das geladene System hat, ihn nicht liest.

 # touch -m 0600 /root/key # head -c16 /dev/urandom > /root/key 

Die Schlüsseldatei enthält genügend wirklich zufällige Bits, sodass der langsame PBKDF-Algorithmus, der einen schwer zu wählenden Verschlüsselungsschlüssel aus einer möglicherweise schwachen Schlüsselphrase erstellt, nicht wirklich benötigt wird. Daher können Sie beim Hinzufügen eines Schlüssels die Anzahl der Iterationen reduzieren:

 # cryptsetup luksAddKey --key-slot=6 --iter-time=1 /dev/sda2 /root/key Enter any existing passphrase: 

Wie Sie sehen, wird die Schlüsseldatei auf einer verschlüsselten Festplatte gespeichert und stellt daher kein Sicherheitsrisiko dar, wenn der Computer ausgeschaltet wird.

Schritt 3: Weisen Sie Speicherplatz im physischen Speicher zu, um den Schlüssel zu speichern

Linux verfügt über mindestens drei verschiedene Treiber, mit denen Sie unter einer bekannten Adresse auf den physischen Speicher zugreifen können. Dies ist linux/drivers/char/mem.c , das auch für das Gerät /dev/mem , sowie phram Module (emuliert einen MTD-Chip, gibt das Gerät /dev/mtd0 ) und nd_e820 (wird bei der Arbeit mit NVDIMM verwendet, gibt /dev/pmem0 ). Sie alle haben ihre unangenehmen Eigenschaften:

• /dev/mem bei Verwendung von Secure Boot nicht beschreibbar, wenn die Distribution das LOCKDOWN-Patch-Set von Matthew Garrett verwendet (und dieses Patch-Set ist erforderlich, wenn die Distribution Secure Boot mit einem von Microsoft signierten Bootloader unterstützen soll).
• phram unter CentOS und Fedora nicht verfügbar - der Betreuer hat die entsprechende Option beim phram des Kernels einfach nicht aktiviert.
• nd_e820 muss mindestens 128 Megabyte Speicher reservieren - so funktioniert NVDIMM. Dies ist jedoch die einzige Option, die unter CentOS mit Secure Boot ausgeführt wird.

Da es keine ideale Option gibt, werden alle drei unten betrachtet.

Bei Verwendung einer der Methoden ist äußerste Vorsicht geboten, um andere Geräte oder Speicherbereiche als die erforderlichen nicht versehentlich zu beeinträchtigen. Dies gilt insbesondere für Computer, die bereits über MTD-Chips oder NVDIMM-Module verfügen. /dev/mtd0 oder /dev/pmem0 möglicherweise nicht das Gerät, das dem Speicherbereich entspricht, der zum Speichern des Schlüssels reserviert ist. Die Nummerierung vorhandener Geräte, auf die sich Konfigurationsdateien und Skripte stützen, kann ebenfalls verwechselt werden. Dementsprechend wird empfohlen, alle Dienste, die auf vorhandenen Geräten /dev/mtd* und /dev/pmem* , vorübergehend zu deaktivieren.

Der physische Linux-Speicher wird memmap indem die memmap Option an den memmap . Wir sind an zwei Arten dieser Option interessiert:

• memmap=4K$0x10000000 reserviert (d. memmap=4K$0x10000000 . Markierungen sind reserviert, damit der Kernel selbst keine verwendet) 4 Kilobyte Speicher, beginnend mit der physischen Adresse 0x10000000;
• memmap=128M!0x10000000 markiert 128 Megabyte physischen Speicher, beginnend bei der Adresse 0x10000000, als NVDIMM (offensichtlich falsch, aber für uns ausreichend).

Die Option c $ ist für die Verwendung mit /dev/mem und phram , die Option c ! - für nd_e820 . Bei Verwendung von $ Startadresse des reservierten Speichers ein Vielfaches von 0x1000 (d. H. 4 Kilobyte) sein, wenn ! - ein Vielfaches von 0x8000000 (d. 0x8000000 . 128 Megabyte).

Wichtig: Das Dollarzeichen ( $ ) in den GRUB-Konfigurationsdateien ist ein Sonderzeichen und muss maskiert werden. Und zweimal: einmal - beim Generieren von grub.cfg aus /etc/default/grub , ein zweites Mal - beim Interpretieren der resultierenden Konfigurationsdatei beim Booten. Das heißt, In /etc/default/grub sollte eventuell die folgende Zeile erscheinen:

 GRUB_CMDLINE_LINUX="memmap=4K\\\$0x10000000 ...  ..." 

Ohne das $ -Zeichen doppelt zu umgehen, startet das System einfach nicht, da es denkt, dass es nur 4 Kilobyte Speicher hat. Es gibt keine derartigen Schwierigkeiten mit einem Ausrufezeichen:

 GRUB_CMDLINE_LINUX="memmap=128M!0x10000000 ...  ..." 

Die physische Speicherkarte (und es wird benötigt, um herauszufinden, welche Adressen reserviert werden sollen) ist für den root in der /proc/iomem :

 # cat /proc/iomem ... 000f0000-000fffff : reserved 000f0000-000fffff : System ROM 00100000-7ffddfff : System RAM 2b000000-350fffff : Crash kernel 73a00000-7417c25e : Kernel code 7417c25f-747661ff : Kernel data 74945000-74c50fff : Kernel bss 7ffde000-7fffffff : reserved 80000000-febfffff : PCI Bus 0000:00 fd000000-fdffffff : 0000:00:02.0 ... 

Der RAM ist als "System RAM" gekennzeichnet. Es reicht aus, eine seiner Seiten für die Speicherung des Schlüssels zu reservieren. Das Erraten, welcher Teil des BIOS-Speichers beim Neustart nicht berührt wird, funktioniert im Voraus nicht zuverlässig. Es sei denn, es gibt einen anderen Computer mit genau derselben BIOS-Version und derselben Speicherkonfiguration, auf dem dieses Handbuch bereits abgeschlossen wurde. Daher müssen Sie im allgemeinen Fall durch Ausprobieren handeln. Beim Neustart des BIOS werden die Daten in der Regel nur am Anfang und am Ende jedes Speicherbereichs geändert. Normalerweise reicht es aus, 128 Megabyte ( 0x8000000 ) von den Rändern zurückzuziehen. Für virtuelle KVM-Maschinen mit 1 GB Speicher oder mehr memmap=4K$0x10000000 die vorgeschlagenen Optionen ( memmap=4K$0x10000000 und memmap=128M!0x10000000 ).

Bei Verwendung des phram Moduls benötigen phram einen weiteren Kernel-Befehlszeilenparameter, der dem Modul tatsächlich mitteilt, welcher physische Speicher verwendet werden soll - unser reservierter. Der Parameter heißt phram.phram und besteht aus drei Teilen: dem Namen (beliebig bis zu 63 Zeichen, wird in sysfs ), der Startadresse und der Länge. Die Startadresse und Länge müssen mit der in memmap , die Suffixe K und M nicht unterstützt.

 GRUB_CMDLINE_LINUX="memmap=4K\\\$0x10000000 phram.phram=savedkey,0x10000000,4096 ..." 

Nach dem Bearbeiten von /etc/default/grub Sie die reale Konfigurationsdatei neu generieren, die GRUB beim Booten liest. Der richtige Befehl hierfür hängt von der Verteilung ab.

 # grub2-mkconfig -o /boot/grub2/grub.cfg # CentOS (Legacy BIOS) # grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg # CentOS (UEFI) # update-grub # Debian, Ubuntu # update-bootloader --reinit # SUSE 

Nach dem Aktualisieren der GRUB-Konfiguration sollte der Computer neu gestartet werden. Wir werden dies jedoch später tun, wenn wir initramfs aktualisieren.

Vierter Schritt: Konfigurieren Sie LUKS so, dass der Schlüssel aus dem Speicher gelesen wird

/etc/crypttab Einstellungen für die /etc/crypttab werden in der /etc/crypttab . Jede Zeile besteht aus vier Feldern:

• das Gerät, das beim Entsperren erhalten werden soll,
• verschlüsseltes Gerät
• Woher bekommt man die Schlüsseldatei ( none bedeutet, dass man eine Schlüsselphrase über die Tastatur eingibt),
• optionales Feld für Optionen.

Wenn die Schlüsseldatei vorhanden ist, aber nicht passt, fragt Dracut nach der Schlüsselphrase. Was in der Tat beim ersten Start erforderlich sein wird.

Ein Beispiel für die /etc/crypttab aus einer frisch installierten Distribution:

 # cat /etc/crypttab #   luks-d07....69 UUID=d07....69 none 

Die Schlüsseldatei in unserem Fall ist ein Stück physischen Speichers. Das heißt, /dev/mem , /dev/mtd0 oder /dev/pmem0 , abhängig von der ausgewählten Speicherzugriffstechnologie. Optionen sind erforderlich, um anzugeben, welcher Teil der Datei der Schlüssel ist.

 # cat /etc/crypttab #   #   /dev/mem: luks-d07....69 UUID=d07....69 /dev/mem keyfile-offset=0x10000000,keyfile-size=16 #   phram: luks-d07....69 UUID=d07....69 /dev/mtd0 keyfile-size=16 #   nd_e820: luks-d07....69 UUID=d07....69 /dev/pmem0 keyfile-size=16 

Das ist nur so, dass es so nicht funktioniert.

Der Punkt ist, wie systemd bestimmt, wann ein Gerät entsperrt werden kann. Er nimmt nämlich das Gerät aus der dritten Spalte und wartet darauf, dass die entsprechende Geräteeinheit aktiv wird. Es scheint logisch: Es macht keinen Sinn, den LUKS-Container zu entsperren, bis ein Gerät mit einer Schlüsseldatei angezeigt wird. Die Geräteeinheit ist jedoch nicht mit dem Gerät selbst identisch. Systemd erstellt standardmäßig Geräteeinheiten nur für Kernelgeräte, die sich auf Subsysteme von Blockgeräten und Netzwerkschnittstellen beziehen. Die Geräte /dev/mem und /dev/mtd0 sind /dev/mtd0 , werden daher nicht standardmäßig überwacht und werden niemals als bereit erkannt.

Sie müssen systemd mitteilen, dass er sie verfolgen soll, indem Sie udev-Regeln in der Datei /etc/udev/rules.d/99-mem.rules erstellen:

 # /dev/mem KERNEL=="mem", TAG+="systemd" # /dev/mtd* KERNEL=="mtd*", TAG+="systemd" #  /dev/pmem*       

Fünfter Schritt: Initramfs neu generieren

Ich erinnere Sie daran: Dieser Artikel behandelt nur Distributionen mit Dracut. Einschließlich solcher, bei denen es nicht standardmäßig verwendet wird, aber zugänglich und effizient ist.

Sie müssen initramfs neu /etc/crypttab Datei /etc/crypttab dort zu aktualisieren. Und auch - um dort zusätzliche Kernelmodule und udev-Regeln aufzunehmen. Andernfalls wird das Gerät /dev/mtd0 oder /dev/pmem0 nicht erstellt. Der Konfigurationsparameter Dracut force_drivers ist für das Aktivieren und Laden zusätzlicher Kernelmodule verantwortlich, und install_items ist für zusätzliche Dateien verantwortlich. Wir erstellen die Datei /etc/dracut.conf.d/mem.conf mit folgendem Inhalt (ein Leerzeichen nach dem öffnenden Anführungszeichen ist erforderlich, dies ist ein Trennzeichen):

 #   /dev/mem: install_items+=" /etc/udev/rules.d/99-mem.rules" #   phram: install_items+=" /etc/udev/rules.d/99-mem.rules" force_drivers+=" phram" #   nd_e820: force_drivers+=" nd_e820 nd_pmem" 

Eigentlich Regeneration initramfs:

 # dracut -f 

Für Debian- und Ubuntu-Benutzer hat der Betreuer einen Rake gesetzt: Die resultierende Datei wird falsch aufgerufen. Sie müssen es umbenennen, damit es wie in der GRUB-Konfiguration beschrieben benannt wird:

 # mv /boot/initramfs-5.0.0-19-generic.img /boot/initrd.img-5.0.0-19-generic 

Bei der Installation neuer Kernel wird die automatische Erstellung von initramfs über Dracut korrekt ausgeführt. Der Fehler betrifft nur den manuellen Start von dracut -f .

Schritt 6: Starten Sie Ihren Computer neu

Ein Neustart ist erforderlich, damit die Änderungen an der GRUB- und Dracut-Konfiguration wirksam werden.

 # reboot 

Zu diesem Zeitpunkt befindet sich kein Schlüssel im Speicher, daher müssen Sie eine Passphrase eingeben.

Nach dem Neustart müssen Sie überprüfen, ob die Speichersicherung ordnungsgemäß funktioniert hat. In der /proc/iomem gewünschte Speicherort /proc/iomem als "reserviert" (bei Verwendung von /dev/mem oder phram ) oder als "persistenter Speicher (Legacy)" markiert sein.

Wenn Sie phram oder nd_e820 Sie sicherstellen, dass sich das Gerät /dev/mtd0 oder /dev/pmem0 wirklich auf den zuvor reservierten Teil des Speichers bezieht und nicht auf etwas anderes.

 # cat /sys/class/mtd/mtd0/name #  : "savedkey" # cat /sys/block/pmem0/device/resource #     

Wenn dies nicht der /dev/mtd* ist, müssen Sie herausfinden, welches der Geräte /dev/mtd* oder /dev/pmem* "unser" ist, und dann / etc / crypttab reparieren, initramfs neu generieren und das Ergebnis nach einem weiteren Neustart erneut überprüfen.

Siebter Schritt: Konfigurieren Sie das Kopieren der Schlüsseldatei in den Speicher

Die Schlüsseldatei wird vor dem Neustart in den Speicher kopiert. Eine Möglichkeit, einen Befehl in der Phase des Herunterfahrens des Systems auszuführen, besteht darin, ihn in der ExecStop Direktive im systemd-Dienst zu registrieren. Damit systemd versteht, dass dies kein Daemon ist und nicht auf das Fehlen der ExecStart Direktive ExecStart , müssen Sie den ExecStart als ExecStart angeben und vorschlagen, dass der Dienst ausgeführt wird, auch wenn ihm kein Arbeitsprozess zugeordnet ist. Hier ist also die Datei /etc/systemd/system/savekey.service . Es muss nur eine der angegebenen Varianten der ExecStop Direktive ExecStop .

 [Unit] Description=Saving LUKS key into RAM Documentation=https://habr.com/ru/post/457396/ [Service] Type=oneshot RemainAfterExit=true #   /dev/mem: ExecStop=/bin/sh -c 'dd if=/root/key of=/dev/mem bs=1 seek=$((0x10000000))' #   /dev/mtd0: ExecStop=/bin/dd if=/root/key of=/dev/mtd0 #   /dev/pmem0: ExecStop=/bin/dd if=/root/key of=/dev/pmem0 [Install] WantedBy=default.target 

Die Konstruktion mit /bin/sh benötigt, da dd die hexadezimale Notation nicht versteht.

Wir aktivieren den Service, überprüfen Sie:

 # systemctl enable savekey # systemctl start savekey # reboot 

Während des anschließenden Neustarts müssen Sie die Passphrase nicht von der Festplatte eingeben. Und falls erforderlich, bedeutet dies normalerweise, dass die Startadresse des reservierten Speicherbereichs falsch ausgewählt ist. Es ist in Ordnung, mehrere Dateien zu reparieren und neu zu generieren und den Computer zweimal neu zu starten.

Bei Verwendung von phram oder nd_e820 nur die GRUB-Konfiguration bearbeitet werden. Bei Verwendung von /dev/mem Startadresse auch in /etc/crypttab (daher müssen initramfs neu /etc/crypttab werden) und im systemd-Dienst erwähnt.

Das ist aber noch nicht alles.

Sicherheitsprobleme

Jede Diskussion über Sicherheitsprobleme basiert auf einem Bedrohungsmodell. Das heißt, auf die Ziele und Mittel des Angreifers. Mir ist bekannt, dass einige der folgenden Beispiele weit hergeholt sind.

Situationen mit physischem Zugriff auf einen ausgeschalteten Computer unterscheiden sich nicht von Situationen ohne konfigurierten Schlüsselspeicher im Speicher. Es gibt dieselben Arten von Angriffen, die darauf abzielen, Schlüsselbegriffe zu erhalten, einschließlich Evil Maid , und dieselben Sicherheitsfunktionen . Wir hören nicht bei ihnen auf, da es nichts Neues gibt.

Interessantere Situationen sind, wenn der Computer eingeschaltet ist.

Situation 1 . Der Angreifer hat keinen physischen Zugriff auf den Computer, kennt die Passphrase nicht, hat jedoch Root-Zugriff über ssh. Das Ziel ist der Schlüssel zum Entschlüsseln der Festplatte. Zum Beispiel, um auf alte sektorweise Sicherungen eines Festplattenabbilds einer virtuellen Maschine zuzugreifen.

Tatsächlich befindet sich der Schlüssel auf der Untertasse in der Datei /root/key . Die Frage ist, in welcher Beziehung dies zu dem steht, was vor der Implementierung dieser Anweisung passiert ist. Antwort: Für luks1 ist die Bedrohung nicht neu. Es gibt einen dmsetup table --target crypt --showkeys , der den Hauptschlüssel anzeigt, d. H. auch Daten, die den Zugriff auf alte Backups ermöglichen. Für luks2 findet die Sicherheitsreduzierung in diesem Szenario tatsächlich statt: dm-crypt-Schlüssel werden auf Kernelebene im Schlüsselbund gespeichert, und es ist unmöglich, sie aus dem Benutzerbereich heraus zu betrachten.

Situation 2 . Der Angreifer kann die Tastatur verwenden und auf den Bildschirm schauen, ist jedoch nicht bereit, das Gehäuse zu öffnen. Zum Beispiel habe ich das durchgesickerte Passwort von IPMI verwendet oder eine noVNC-Sitzung in der Cloud abgefangen. Er kennt den Schlüsselbegriff nicht, er kennt auch keine anderen Passwörter. Das Ziel ist der Root-Zugriff.

Bitte: Starten Sie über Ctrl-Alt-Del , und fügen Sie die Kernel-Option init=/bin/sh über GRUB hinzu. Die Passphrase wurde nicht benötigt, da der Schlüssel erfolgreich aus dem Speicher gelesen wurde. Um sich davor zu schützen, müssten Sie GRUB daran hindern, das zu laden, was nicht im Menü enthalten ist. Leider ist diese Funktionalität in verschiedenen Distributionen unterschiedlich implementiert.

Ab Version 7.2 verfügt CentOS über den grub2-setpassword , der GRUB tatsächlich mit einem Kennwort schützt. Andere Distributionen verfügen möglicherweise über eigene Dienstprogramme für dieselbe Aufgabe. Wenn keine vorhanden sind, können Sie die Dateien im Verzeichnis grub.cfg direkt bearbeiten und grub.cfg .

/etc/grub.d/10_linux Datei /etc/grub.d/10_linux die Variable CLASS und fügen --unrestricted am Ende die Option --unrestricted , falls sie nicht vorhanden war:

 CLASS="--class gnu-linux --class gnu --class os --unrestricted" 

/etc/grub.d/40_custom Datei /etc/grub.d/40_custom die Zeilen hinzu, in denen der Benutzername und das Kennwort angegeben sind, die zum Bearbeiten der Kernel-Befehlszeile erforderlich sind:

 set superusers="root" password_pbkdf2 root grub.pbkdf2....... #    grub2-mkpasswd-pbkdf2 

Oder wenn eine solche Funktionalität überhaupt deaktiviert werden muss, ist hier eine Zeile wie diese:

 set superusers="" 

Situation 3 . Der Angreifer hat Zugriff auf den mitgelieferten Computer, sodass Sie von nicht vertrauenswürdigen Medien booten können. Dies kann ein physischer Zugriff ohne Öffnen des Gehäuses oder ein Zugriff über IPMI sein. Das Ziel ist der Root-Zugriff.

Es kann seinen GRUB von einem USB-Flash-Laufwerk oder einer CD-ROM laden und init=/bin/sh zu Ihren Kernel-Parametern hinzufügen, wie im vorherigen Beispiel. Dementsprechend sollte das Booten von schrecklichen Medien im BIOS verboten werden. Und schützen Sie auch die Änderung der BIOS-Einstellungen mit einem Passwort.

Situation 4 . Der Angreifer hat physischen Zugriff auf den mitgelieferten Computer, einschließlich der Möglichkeit, den Fall zu öffnen. Ziel ist es, den Schlüssel herauszufinden oder Root-Zugriff zu erhalten.

Im Allgemeinen ist dies ohnehin eine Verlustsituation. Der Angriff auf Speichermodule durch Abkühlen ( Kaltstartangriff ) wurde nicht abgebrochen. Auch theoretisch (nicht überprüft) können Sie die Tatsache nutzen, dass moderne SATA-Festplatten Hot-Reconnection unterstützen. Wenn Sie den Computer neu starten, trennen Sie die Festplatte, ändern Sie grub.cfg in init=/bin/sh , stellen Sie die Verbindung wieder her und lassen Sie das System neu starten. Es stellt sich heraus (wenn ich es richtig verstehe), Root-Zugriff.

Ungefähr das Gleiche kann ein skrupelloser Mitarbeiter eines Cloud-Hostings tun, indem er einen Schnappschuss einer virtuellen Maschine mit ihrer nachfolgenden Änderung erstellt.

Andere Angelegenheiten

Es ist ein Spott, den Schlüssel während eines Neustarts im Speicher zu behalten. Use-after-free in seiner reinsten Form. Eine sauberere Lösung besteht darin, kexec zu verwenden und den Schlüssel zu dynamisch generierten initramfs hinzuzufügen. Es schützt auch vor dem Ersetzen von Kernel-Parametern . Ja, wenn kexec funktioniert. Moderne Distributionen haben die Kexec-Konfiguration zu kompliziert gemacht .

In Rechenzentren und vor allem in der Cloud verschwindet die Stromversorgung nie. Es stellt sich heraus, dass der Schlüsselbegriff nicht mehr benötigt wird? Wenn Sie sich dessen so sicher sind, können Sie es löschen. Es wird sich herausstellen, dass es sich um einen funktionierenden Server handelt, dessen Schlüssel für die Festplatte niemand kennt¹ und der daher nicht ausgegeben wird, sondern dessen System mit regulären Mitteln aktualisiert werden kann. — sudo poweroff .

¹ /root/key — , cron.

? IPMI, . IPMI Java. .

? SSH . ! . , sudo reboot , ?

, . SSH , . , , .