Hallo,

inzwischen habe ich die Lösung mit ein bisschen Tüfteln gefunden:

da zum Zeitpunkt der Initialisierung des loopback-scripts die hierfür notwendige /var-Partition noch nicht zur Verfügung steht muss der Initialisierungszeitpunkt verschoben werden und zwar direkt hinter die Initialisierung des cryptdisks-scripts:

im Ordner /etc/rcS.d/ verschieben wir S08loopback hinter S28cryptdisks durch sudo cp -avx S08loopback S29loopback und dann das alte Script löschen mit sudo rm S08loopback. Geht warscheinlich auch einfacher mit sudo mv …

Beim anschliessenden Test funktionierte bei mir alles perfekt, das Netzwerk (und loopback-device) wurde erst nach Entschüsselung der verschlüsselten Partitionen initialisiert.

Gruss

25-386 geht ja nicht, aber wie sieht es mit 26-server aus?

Der 2.6.15-26-server - Kernel läuft einwandfrei!

Der Sinn hinter einer kompletten Systemverschlüsselung verschliesst sich mir noch etwas. Was verspricht man sich davon?

Hmm… Prinzip?!? Ich will auf Nummer sicher gehen und verschlüssele so viel wie möglich… : /home würd eigentlich reichen, aber wer weiß…

Der Sinn einer Komplettverschlüsselung ist, dass ein „Angreifer“ nichts über die installierten Programme erfährt.

Findet man auf einem Rechner zB Spezialsoftware, die zur Analyse von Finanzmarktdaten verwendet wird, dann lässt dies schon einige Schlüsse zu (und wenn es der Trugschluss ist, der Besitzer muss ein reicher Börsianer sein, und deswegen viel Steuern bezahlen - die er aber eben nicht bezahlt hat)

Und auch wenn Software installiert ist, mit denen zB in der Rüstungsindustrie Konstruktionspläne erstellt werden, könnte man dabei auf den einen oder anderen Gedanken kommen …

Das erklärt mir aber nicht den Sinn von Komplettverschlüsselungen. Software liegt zB in /usr oder ähnlichen Partitionen nicht in /
Und wenn ich Software nutze, die sicherheitstechnisch ääääh „speziell“ behandelt werden soll, dann wird die in einer speziellen Partition liegen.

Naja aber wenn etwas im swap oder /tmp landet? Klar dann verschlüsseln wir noch 2 weitere Partitionen, insgesamt 4 jetzt, mit 4 Passwörtern!!

/ würde ein Passwort benötigen und eventuell dort gespeicherte Schlüssel, was sowieso sicherer ist!!

Das Argument, dass Software nicht direkt in / gespeichert sein wird, ist natürlich korrekt.

Was aber bei einer Verschlüsselung des Gesamtsystems zu tragen kommt, ist plausible deniability.

Ist das Root-Dateisystem (und ich unterstelle jetzt einfach mal auch /etc) nicht verschlüsselt, könnten sich darin Informationen zB in /etc/fstab oder /etc/crypttab zu den verschlüsselten Devices befinden.

So weiß ein potentieller Angreifer zB, dass die Partition /dev/hda5 mit Twofish verschlüsselt ist, und dazu luks in Kombination mit cryptsetup eingesetzt wird. Außerdem ist vielleicht so auch noch der Mountpoint ersichtlich (zB /home).

Sucht man zB nach Dokumenten eines Users wird man diese Partition näher betrachten. Und mit den Informationen über die Art der Verschlüsselung ist eine Kryptoanalyse ungleich einfacher als ohne eben diese.

Ist nun aber das Gesamtsystem verschlüsselt (also nur eine einzige unverschlüsselte Partition, eingehängt unter /boot) existent, kann man daraus lediglich Informationen über physische Position und Art der Root-Partition erhalten.

Ob sich auf den anderen zB 5 Partitionen des Rechners auch verschlüsselte Daten befinden, oder ob diese bloß mit Zufallsdatenmüll geshreddert wurden, lässt sich nicht mehr feststellen.

Heißt also, im Fall des Falles kann man argumentieren, die Daten aller Partitionen bis auf die Root-Partition vernichtet zu haben, und keiner kann das Gegenteil beweisen.

Eigentlich könnte dies auch genauso für die Root-Partition zutreffen, aber ich denke die Frage nach einem Passwort beim Booten für diese ist zu offensichtlich

löwe hat geschrieben:

Was aber bei einer Verschlüsselung des Gesamtsystems zu tragen kommt, ist plausible deniability.

Ist das Root-Dateisystem (und ich unterstelle jetzt einfach mal auch /etc) nicht verschlüsselt, könnten sich darin Informationen zB in /etc/fstab oder /etc/crypttab zu den verschlüsselten Devices befinden.

So weiß ein potentieller Angreifer zB, dass die Partition /dev/hda5 mit Twofish verschlüsselt ist, und dazu luks in Kombination mit cryptsetup eingesetzt wird. Außerdem ist vielleicht so auch noch der Mountpoint ersichtlich (zB /home).

Sucht man zB nach Dokumenten eines Users wird man diese Partition näher betrachten. Und mit den Informationen über die Art der Verschlüsselung ist eine Kryptoanalyse ungleich einfacher als ohne eben diese.

Ist nun aber das Gesamtsystem verschlüsselt (also nur eine einzige unverschlüsselte Partition, eingehängt unter /boot) existent, kann man daraus lediglich Informationen über physische Position und Art der Root-Partition erhalten.

Ob sich auf den anderen zB 5 Partitionen des Rechners auch verschlüsselte Daten befinden, oder ob diese bloß mit Zufallsdatenmüll geshreddert wurden, lässt sich nicht mehr feststellen.

Hmm ich sehe das eher als eine Art „Security through obscurity“. Ist halt diskussionwürdig (und wird auch immer wieder kontrovers diskutiert), ob sowas einen wirklichen Sicherheitsschub bringt. Ich persönlich finde, daß die Wahl eines entsprechend sicheren Verschlüsselungsverfahrens bzw eines entsprechend starken Schlüssel viel mehr bringt.

löwe hat geschrieben:

Heißt also, im Fall des Falles kann man argumentieren, die Daten aller Partitionen bis auf die Root-Partition vernichtet zu haben, und keiner kann das Gegenteil beweisen.

Eigentlich könnte dies auch genauso für die Root-Partition zutreffen, aber ich denke die Frage nach einem Passwort beim Booten für diese ist zu offensichtlich

Zuerst muß mir mal jemand nachweisen, daß auf der verschlüsselten Partition Daten existieren. Warum sollte ich argumentieren, etwas vernichtet zu haben, wenn ich auch argumentieren kann, gar keine Daten zu haben?

Sachen wie /tmp kann man als RAMdisk gestalten.

Wie gesagt, ich kann für einen Ottonormaluserrechner einfach kein Bedrohungsszenario finden, welches eine Vollverschlüsselung fordert, welche im Endeffekt ja immer eine verringerte Rechnerperformance bedeutet.

Ich habe jetzt mal eine technische Frage zur Komplettverschlüsselung wie hier beschrieben

Wenn ich eine solche verschlüsselte Partition mittels LVM verwalte, kann ich sie dann noch immer problemlos im Nachhinein vergrößern und verkleinern oder funktioniert dies ausschließlich bei unverschlüsselten Partitionen?

Noch eine andere Frage: Was ist eurer Meinung nach besser? Eine verschlüsselte LVM-Partition, auf der sich dann „normale“ Logical Volumes befinden,
oder eine „normale“ LVM-Partition, und die Logical Volumes verschlüsseln?

Nachdem also nun das LVM steht, wird es Zeit, das gute Stück zu verschlüsseln. Sinnvollerweise wird das lv und nicht das pv verschlüsselt, so dass später problemlos die Größe weiter angepasst werden kann.

Ich nutze allerdings kein LVM, also kann ich es nicht bestätigen…

Falls es jemanden hier interessieren sollte, habe ich gerade gefunden:

Frage: Kann man LVs auch verschlüsseln? Wie am besten?

Antwort: Eine LV verhält sich vom Prinzip her genau so wie eine Partition (also wie jedes andere Blockdevice). Daher kann man sie entweder mit dmcrypt (Device Mapper Crypt, das Programm heißt cryptsetup zumindest unter Debian) oder cryptoloop verschlüsseln. Ich selbst setzte dmcrypt mit aes auf einer LV ein und es funktioniert bisher problemlos. – HelmutGrohne 2005-11-14 21:34:09

Quelle: http://www.linuxwiki.de/LVM

Ich werde es in den nächsten Tagen testen und dann hier davon berichten.

Hi,

mal ganz doof gefragt: Wieso hängt das Funktionieren von der Kernelversion ab? Und wieso unterstützt ein älterer Kernel die Verschlüsselung, ein neuerer aber nicht?
Und wie siehts eigentlich mit den amd64-Kerneln aus? Ich habe momentan 2.6.15.26-amd64 installiert (musste Kernel wegen ATI-Treibern einspielen). Würde es damit funktionieren?
Ich nehme an, dass ein Umstieg auf den alten Kernel, den Treiber außer Gefecht setzen würde?

Und vorausgesetzt, mit meinem aktuellen Kernel würde es funktionieren, kann ich mir dann das nächste Kernelupdate stecken, da sonst das System versagen würde?

Fragen über Fragen, ich hoffe ihr könnt mir vergeben - oder noch besser - sie mir beantworten

Grüße