Partitionierung eines komplett verschlüsselten Linux-Systems - Versionsgeschichte

Gehrke: /* Prozessbeschreibung Systemupdates */ Abhängigkeit zum Patch-Prozess

2015-01-28T06:34:29Z

‎Prozessbeschreibung Systemupdates: Abhängigkeit zum Patch-Prozess

Gehrke: 'Festplatten-Kapazität erweitern (mdadm + LVM + LUKS)' hinzugefügt

2015-01-13T13:44:40Z

'Festplatten-Kapazität erweitern (mdadm + LVM + LUKS)' hinzugefügt

Gehrke: Formatierung der Warnungen in Achtung-Boxen - nichts Inhaltliches

2013-12-11T08:18:54Z

Formatierung der Warnungen in Achtung-Boxen - nichts Inhaltliches

Gehrke: interne Verlinkung - nichts inhaltliches

2013-12-10T21:24:03Z

interne Verlinkung - nichts inhaltliches

Gehrke: /* /boot auslagern */ interne Verlinkung

2013-12-10T21:22:56Z

‎/boot auslagern: interne Verlinkung

Gehrke: Category

2013-11-23T07:31:04Z

Cve: /* Einschränkungen */ mehr Links ...

2013-07-20T10:45:21Z

‎Einschränkungen: mehr Links ...

Cve: Link: Initialer Thread linux-club.de

2013-07-20T08:50:01Z

Link: Initialer Thread linux-club.de

Cve: /* Einschränkungen */

2013-07-20T08:43:57Z

‎Einschränkungen

Cve: /* Einschränkungen */ Suspend-To-RAM (STR)

2013-07-20T08:35:06Z

‎Einschränkungen: Suspend-To-RAM (STR)

@@ Zeile 81: / Zeile 81: @@
 =Prozessbeschreibung Systemupdates=
-*Während eines Systemupdates von 'grub2' oder 'kernel' muss der Stick gemountet sein.
+*Während eines Systemupdates von 'grub2' oder 'kernel' muss der Stick gemountet sein (s. [[GRUB2#Abhängigkeit zum Patch-Prozess|Abhängigkeit zum Patch-Prozess]]).
 *Unmittelbar nach dem Update wird im gecrypteten Bereich ein Image des Sticks als Archiv abgelegt, woraus zu jedem beliebigen Zeitpunkt ein neuer Boot-Stick erzeugt werden kann:
 <pre>

@@ Zeile 166: / Zeile 166: @@
 =Links=
 *[http://www.linux-club.de/viewtopic.php?f=4&t=118035 Initialer Thread linux-club.de: grub2: gecryptete Boot-Partition]
 [[Category:Partitionen]] [[Category:Security]] [[Category:Bootmanager]]

@@ Zeile 89: / Zeile 89: @@
 2004877312 bytes (2.0 GB) copied, 99.6817 s, 20.1 MB/s
 </pre>
-'''Achtung:''' Unbedingt die Benennung des richtigen Devices beachten. Die Ausführung von [[dd]] auf das falsche Laufwerk kann '''alle Daten dort zerstören'''!
+{{Box Achtung||Unbedingt die Benennung des richtigen Devices beachten. Die Ausführung von [[dd]] auf das falsche Laufwerk kann '''alle Daten dort zerstören'''!}}
 *Es müssen '''alle'''  (sicher deponierten!) Boot-Sticks aktualisiert werden:
@@ Zeile 162: / Zeile 162: @@
 linux:/home/linux # umount /root/home
 </pre>
-'''Achtung:''' Unbedingt die Benennung des richtigen Devices beachten. Die Ausführung von [[dd]] auf das falsche Laufwerk kann '''alle Daten dort zerstören'''!
+{{Box Achtung||Unbedingt die Benennung des richtigen Devices beachten. Die Ausführung von [[dd]] auf das falsche Laufwerk kann '''alle Daten dort zerstören'''!}}
 =Links=

@@ Zeile 2: / Zeile 2: @@
 [[Bild:partitionierung-notebook.png|center|thumb|879px|Partitionierung mit einem großen Crypt-Container auf 'md1', aber 'md0' ist unverschlüsselt]]
 Einzige Ausnahme bei diesem Setup ist das Dateisystem '/boot', welches unverschlüsselt auf einer relativ kleinen Partition liegt. Dort liegen:
-*der Boot-Manager [[grub2]]
+*der Boot-Manager [[GRUB 2]]
 *die Kernel und InitialRamDisks der installierten Betriebssysteme
 Ein solches Setup sichert die Daten im verschlüsselten Bereich gut ab gegen Angriffsszenarien wie '''Diebstahl''' oder '''Verlust''' der Hardware.

@@ Zeile 25: / Zeile 25: @@
 =Schutzmaßnahmen=
 ==/boot auslagern==
-Ein erster (naiver) Ansatz wäre, die Boot-Partition ebenfalls zu verschlüsseln. Das scheitert aber daran, dass zumindest ein kleiner Bereich prinzipbedingt unverschlüsselt bleiben muss, sonst kann die Software nicht geladen werden. So könnte man zwar möglicherweise mit [[grub2]] den Kernel selbst in einen verschlüsselten Bereich auslagern, aber der Bootloader muss unverschlüsselt bleiben. Das würde das Problem somit nur verlagern und nicht lösen, weil ein Angriff über einen trojanisierten Bootloader den selben Effekt hätte wie mit einem trojanisiertem Kernel.
+Ein erster (naiver) Ansatz wäre, die Boot-Partition ebenfalls zu verschlüsseln. Das scheitert aber daran, dass zumindest ein kleiner Bereich prinzipbedingt unverschlüsselt bleiben muss, sonst kann die Software nicht geladen werden. So könnte man zwar möglicherweise mit [[GRUB 2]] den Kernel selbst in einen verschlüsselten Bereich auslagern, aber der Bootloader muss unverschlüsselt bleiben. Das würde das Problem somit nur verlagern und nicht lösen, weil ein Angriff über einen trojanisierten Bootloader den selben Effekt hätte wie mit einem trojanisiertem Kernel.
 Dieses grundsätzliche Problem kann allein auf Software-Ebene nicht gelöst werden.
@@ Zeile 40: / Zeile 40: @@
 *Boot-Vorgang
 *Suspend-To-Disk
-*Update von [[Grub2]] oder Kernel
+*Update von [[GRUB 2]] oder Kernel
 Ansonsten ist der Stick nicht gemountet und wird an sicherer Stelle aufbewahrt. Die Wirksamkeit dieser Sicherheitmaßnahme wird selbstverständlich durch die Sorgfalt bestimmt, mit der die verwendeten Boot-Sticks gegen unberechtigten Zugriff geschützt werden.

← Nächstältere Version		Version vom 23. November 2013, 07:31 Uhr
Zeile 167:		Zeile 167:
	*[http://www.linux-club.de/viewtopic.php?f=4&t=118035 Initialer Thread linux-club.de: grub2: gecryptete Boot-Partition]		*[http://www.linux-club.de/viewtopic.php?f=4&t=118035 Initialer Thread linux-club.de: grub2: gecryptete Boot-Partition]

−	[[Category:Partitionen]] [[Category:Security]]	+	[[Category:Partitionen]] [[Category:Security]] [[Category:Bootmanager]]

@@ Zeile 49: / Zeile 49: @@
 Auf den ersten Blick erscheint die Vorgehensweise umständlich und ist in Abhängigkeit von der verwendeten Hardware auch relativ langsam. Im konkreten Fall eines Notebooks fallen diese Kriterien aber im laufenden Betrieb kaum ins Gewicht, insbesondere weil das System relativ selten tatsächlich gebootet wird. Stattdessen kommt sehr häufig 'Suspend-To-RAM (STR)' zum Einsatz, bei welchem ein Bootvorgang nicht notwendig ist.
-'''Hinweis:''' ''Suspend-To-RAM (STR)'' birgt ein gewisses Risiko. Hier wird der Inhalt des RAM aktiv gehalten, was zusätzliche Angriffsvektoren offen hält ([https://de.wikipedia.org/wiki/Kaltstartattacke Kaltstartattacke]). Das Risiko besteht auch bei einem laufendem System und ist nicht spezifisch für diese Absicherungsmaßnahme, aber die Verwendung von STR verlängert den Zeitraum, in dem das Risiko besteht. Mehr Sicherheit bietet daher ein sauberer Shutdown oder auch STD.
+'''Hinweis:''' ''Suspend-To-RAM (STR)'' birgt ein gewisses Risiko. Hier wird der Inhalt des RAM aktiv gehalten, was zusätzliche Angriffsvektoren offen hält. Das Risiko besteht auch bei einem laufendem System und ist nicht spezifisch für diese Absicherungsmaßnahme, aber die Verwendung von STR verlängert den Zeitraum, in dem das Risiko besteht. Mehr Sicherheit bietet daher ein sauberer Shutdown oder auch STD.
 Hingegen funktioniert ein 'Suspend-To-Disk (STD)' nur, wenn der Boot-Stick gemountet ist. Fehlermeldung, falls das nicht der Fall ist: