Das letzte Fedora Security Debakel hat gezeigt, dass Schlüssel ohne Passphrase verboten gehören. Jedenfalls falls man Sicherheit als Ziel verfolgt.
PS: Oh Mann, ich war ja auch mal ein überzeugter Gentoo-User ... aber wenn ich jetzt wieder sehe wie viel Arbeit das war. Jeder gute Installer macht es mit 3x mehr Optionen 1000x schneller.
Mein Umstieg von Gentoo auf Ubuntu auf meinem Laptop habe ich echt bereut. Auf meinem Rechner auf Arbeit kommt mir jedenfalls nichts anderes als Gentoo Linux drauf. Ich persönlich finde es frustrierend, wie sich bei Ubuntu Fehler von einer Version in die nächste schleppen, siehe Pulseaudio und Intel ICH HDA Audio, oder wenn bei einem Betatest (9.04) gemeldete Fehler nicht mal von Entwicklern kommentiert werden. Dafür gibt's Cloud-Computing!!! Was nützt einem die schnelle Installation. Lieber Installiere ich mein System einmal 1-2 Tage und es läuft dann über Jahre, als in 30 Minuten und dafür alle 6-12 Monate.
>PS: Oh Mann, ich war ja auch mal ein überzeugter Gentoo-User ... aber wenn ich jetzt wieder sehe wie viel Arbeit das war. Jeder gute Installer macht es mit 3x mehr Optionen 1000x schneller.
Schneller? definitiv!
Aber was sollen 3 mal mehr optionen sein? Grad bei gentoo hast du _SO GUT WIE ALLE_ Optionen, weil die installation eben nicht automatisiert ist. Installer sind dazu da vorgänge zu automatisieren, es ist also grade der sinn eines installers optionen wegzulassen die der distributor für unnötig hält und die installation dadurch zu beschleunigen. Insofern erzählst einfach du unsinn. Ein Installer der _völlig_ flexibel alles erdenkliche während der installation erlaubt wäre die bash oder eine andere shell. Ganz einfach weil er nichts automatisieren könnte für den fall das der user während eines x-beliebigen vorgangs vllt doch das ein oder andere tun will was der distributor nicht vorgesehen hat. Und das gehört nun mal zur philosophie von gentoo, ergo ist die installation per kommandozeile die methode der wahl. Jegliche Installationsanleitungen sind halt eine Hilfe für neulinge um zurecht zu kommen, wenn man sich auskennt installiert man den krempel den man halt braucht ohne anleitung, so schwierig ist das nicht: festplatten partitionieren, basissystem drauf, dieses konfigurieren, den kernel backen, bootloader drauf, software die man will installieren, reboot fertig. Viele Distris automatisieren das, Gentoo halt nicht, eben wegen der Optionen die der User dabei hat. na, begriffen?
Btw, ich schrieb oben _SO GUT WIE ALLE_, weil man bei gentoo natürlich an einige vorgaben gebunden ist.. baselayout, portage und die dependancies wie python, usw usf. müssen sein damit die kiste läuft und sich gentoo schimpfen darf, aber dennoch gibt es meines erachtens nach nur noch LFS um ein nach flexibleres system zu haben.
So etwas komplexes funktioniert mit keinem Linux-Installer. Die sind alle nur für Standardinstallationen gedacht. Sobald du ein Häkchen anders setzt, stürzt der Installer ab, zerstört die Platte, ignoriert das Häkchen oder vermurkst die Installation. Da mußt du schon selber Kernelmodule kompillieren, fstabs editieren und mußt darauf verzichten, Partitionen in der Desktopumgebung mounten zu können. Wenn du Komfort willst, dann geh zu Windows!
Sobald du ein Häkchen anders setzt, stürzt der Installer ab, zerstört die Platte, ignoriert das Häkchen oder vermurkst die Installation. Da mußt du schon selber Kernelmodule kompillieren, fstabs editieren und mußt darauf verzichten, Partitionen in der Desktopumgebung mounten zu können. Wenn du Komfort willst, dann geh zu Windows!
Lass ihn doch Lienuks-FUD verbreiten... je mehr Trottel sich dadurch von Lienuks abhalten lassen, desto besser! ...oder sollen sich alle Foren, Blogs, Newsgroups usw mit DAUs füllen?
Also liebe Leute: Lienuks ist sowas von dermaßen und überhapt generell mehr als nur ein bisschen mindestens von Hinten dem Faß die Krone mitten auf'm Holzweg und das Pferd des Apothekers kotzt. DAS wollt ihr nicht wirklich! Alles klar?
So ein Quatsch! Das hört sich an, als hättest du noch nie mit einem Linux gearbeitet oder es zumindest installiert. Es hört sich so an, als wenn du ohne Verständnis etwas nachplappern würdest, was du auf einem von Microsoft gesponserten Seminar gelernt hast. Ich sage dir jetzt nicht, mit welchen Distributionen das alles sehr elegant geht. Denn ich habe kein Interesse etwas gegen dein Vakuum zu tun.
Falsch geraten. Ich verwende seit acht Jahren ausschließlich Debian und bin weitgehend zufrieden damit. Kein Windows, kein Microsoft installiert.
Mounte mal eine AES256 verschlüsselte Partition! Du mußt das Kernelmodul bauen (dank Debian meistens kein Problem), in /etc/modules eintragen und dann kannst du die Partition mounten. Aber nur in der Konsole, weil KDE nicht in der Lage ist, dich nach dem Passwort zu fragen. Immerhin kannst du eine Zeile in die fstab setzen, sodaß auch Benutzer die Partition mounten können und du nicht jedesmal den vollen mount-Befehl brauchst. Für mich ist das alles kein Problem aber Komfort nenne ich das nicht?
Leute, ich schicke euch mal einen verschlüsselten USB-Stick. Wie wollt ihr auf den zugreifen? Findet ihr es wirklich angebracht, dass jemand, der nur schnell einen solchen Stick einstöpseln will, lange mount-Befehle lernt? Das meine ich. In der Standardsitiation ist alles kein Problem: Ich trage die verschlüsselte Partition in die fstab ein und kann sie mounten. Vielleicht gibt es Tools dafür. Wenn, dann sind sie schwer zu finden. Aber sobald ich vom Üblichen abweiche und z.B. mein USB-Stick verschlüsselt ist, komme ich so kein Stück weiter.
Für verschlüsselte Wechselmedien gibt es portablere Lösungen. TrueCrypt beispielsweise richtet sich an Mausschubser und solche dies es werden wollen.
Ich weiß jetzt allerdings nicht ob TrueCrypt unter *BSD läuft.
cryptsetup ist eine Linux Lösung und die Einbindung in den Bootprozess ist _extrem_ Distributionsabhängig. Unter Ubuntu erkannte er zwar meine container, fragte aber ständig nach einem Passwort. Ohne meine Keys aus einem verschlüsselten Container bringt aber das beste Passwort nichts. Insofern ist Automount für meine verschlüsselten Datenträger komplett nutzlos.
Fazit: Noch ist Verschlüsselung unter Linux ein Spezialgebiet. Man kann verschlüsselte Datenträger einer Distribution in eine andere Einbinden, es geht aber nur von Hand. Im Bootprozess ist diese Fähigkeit noch stärker eingeschränkt.
TrueCrypt wendet sich an diejenigen, die einfach etwas verschlüsseln wollen.
Wenn dein Ziel nur irgendein einsatzfähiger Desktop ist gebe ich dir vollkommen recht.
Gentoo spielt seine Stärken auf zwei Gebieten aus: 1. Lerneffekt 2. Sonderwünsche!
Wenn du mal versuchst ein System nur mit den nötigsten Paketen und einigen SVN versionen aufzusetzen stößt du mit anderen Distributionen schnell an die Grenzen und der Aufwand übersteigt den einer Gentoo Installation deutlich.
Die Einträge mit USE=static sollten aber eventuell in die package.use eingetragen werden sonst gibt es nach dem nächsten großen system-update ein böses Erwachen, wenn die root-partition nicht mehr gelesen werden kann !
Ich hab den Beitrag nur überflogen und in die bookmarks für die nächste neuinstallation gepackt, aber soweit ich das nachvollziehen konnte werden die statischen binaries ins initramfs kopiert und laufen von da, weitere updates sind dann wieder dynamisch, tangieren allerdings die statischen nicht.
Aber im Prinzip reisst du einen wichtigen Punkt an - die statischen binaries werden nicht geupdated und schlummern im initramfs rum, irgendwann mal bekommt man ein problem wenn man nicht selbst dran denkt diese ab und zu mal aufzufrischen.
Ich habe ein kleines Script, welches veränderungen an der boot partition erkennt (anhand des letzten backups) und anzeigt, welche files modifiziert wurden. Es erzeugt ein backup der /boot-Partition und speichert das image selber im Verzeichnis /boot (das image ist sichtbar, solange die bootpartition nicht gemounted wurde). Mit dem parameter --update kann man ein neues backup anlegen. Wenn das Script beim Booten (aus dem encrypted root) gestartet wird, überprüft es die boot-partition und die file-signaturen und bietet an, ein Backup (für späteres Analyse) zu machen, oder aber das letzte boot-image zurückzuspielen
gentoo-c2q bootsigcheck # ./bootsig --check Checking image and boot device signature... Comparing file signatures... (( the following file signatures didnt match: /boot/tmp_mnt/grub/menu.lst: /boot/tmp_mnt/grub/grub.conf:
COnt = continue with boot (you know what you do) SHell = enter emergency shell (busybox) RESTore = restore boot partition from boot image /boot/boot.img BACKup = backup suspect boot partition to /boot/boot.img.suspect BOot = reboot the system HAlt = shutdown now without reboot enter command:
gentoo-c2q bootsigcheck # ./bootsig --update Update boot signatures...required: backing up old boot image... Creating image of boot partition /dev/sda2 as /boot/boot.img... Creating new signature of /dev/sda2... Adding signature of /boot/boot.img... Checking signatures: /dev/sda2: OK /boot/boot.img: OK Success!
irgendwie sieht das ziemlich nach C&P aus einem der diversen Wikis aus, wobei dort in der Regel noch mehr sinnvolles zum Thema zu finden ist...hier fehlt z.B. der Hinweis auf eine ordentliche Vorbereitung der Plate(n) (füllen mit Random-Zeug, etc.).
Desweiteren, warum wird immer noch lrw empfohlen, dass bekanntlich eine potentiell ausnutzbare Lücke hat und mit xts bereits eine bessere/sicherere Technik existiert?
Was mich derzeit an der Verschlüsselung am meisten nervt, ist die Inkompabilität bei verschiedenen Systemen. Ein Austausch von Daten zwischen z.B. Linux *BSD ist auf einer einzelnen Kiste nicht wirklich sinnvoll möglich - LUKS und GEOM/GELI vertragen sich nicht und selbst bei den FS ist immer noch nichts ordentliches in Sicht(@Oracle, wenn das mit Sun klappt, ändert mal die ZFS-Lizenz).
genau. Wenn man schon verschlüsselt, sollte man sich auch die halbe stunde zeit nehmen die hdd vorher mit shred oder dd schön mit zufallszahlen zu füllen. Tut man das nicht, erleichtert man unnötig etwaige crackversuche.
Also für meine Festplatten benötigen meine Rechner schon eher in der Gegend von 12 bis 24 Stunden
Nicht umsonst wünschte ich, das Cryptodevice würde endlich kommen von dem ein Wissenschaftler mal gefaselt hatte (ca. 200 MByte/s echte Zufallszahlen). Das ganze mit PCIe Anschluss und das shredden von TB Platten macht wieder Spaß
Nicht umsonst wünschte ich, das Cryptodevice würde endlich kommen von dem ein Wissenschaftler mal gefaselt hatte (ca. 200 MByte/s echte Zufallszahlen). Das ganze mit PCIe Anschluss und das shredden von TB Platten macht wieder Spaß
Kleiner Tipp: Es reicht, wenn Du den Container z.B. mit Nullen vollschreibst; das geht wesentlich schneller.
Beim Lesen des Artikels sind mir einige Dinge aufgefallen. - Was spricht dagegen für die Erstellung der ramdisk das genkernelpacket zu verwenden? Damit kann man luks, lvm und splashscreens mit einem Konsolenbefehl einbinden. - Würde es für ein mehr an Sicherheit nicht Sinn machen, das Keyfile per GPG zu verschlüsseln? (afaik kann sogar die initramfs vom genkernel damit umgehen) - Warum wird der swap nicht auch verschlüsselt? (geht ja mit dem Auskommentieren einer Zeile relativ einfach) (bin mir nur nicht sicher ob das hibernation noch funktioniert)
Hab den Artikel zwar nicht geschrieben (und auch noch nicht gelesen) will aber trotzdem schon mal meinen Senf dazu geben
>- Würde es für ein mehr an Sicherheit nicht Sinn machen, das Keyfile per GPG zu verschlüsseln? (afaik kann sogar die initramfs vom genkernel damit umgehen)
Auf jeden Fall. Dann benötigt ein Angreifer etwas das du hast (USBstick) und etwas das du weißt (GPG Passwort). Nur spricht man dann meines Wissens nicht mehr von einem Keyfile sondern von einer von GPG gelieferten Passphrase.
>- Warum wird der swap nicht auch verschlüsselt? (geht ja mit dem Auskommentieren einer Zeile relativ einfach) (bin mir nur nicht sicher ob das hibernation noch funktioniert)
Die normale swap Verschlüsselung arbeitet mit Einmalschlüsseln. Hier ist eine Hibernation also so nicht machbar. Für Hibernation müsste swap wie eine verschlüsselte /home eingebunden werden. Ist technisch zwar machbar, meines Wissens aber im Baselayout (auch im 2.x) nicht vorgesehen.
Sollte der Artikel allerdings swap nicht verschlüsseln, dann ist er das Lesen nicht wert. Das ist das Erste was ein guter Crypto Artikel erwähnen sollte.
Swap lässt sich ohne Probleme verschlüsseln, so dass suspend to disk noch funktioniert. Nur Einmalschlüssel lassen sich in diesem Fall natürlich nicht verwenden. Eine Möglichkeit zur Verschlüsselung ist z.B. eine verschlüsselte Partition, die man mittels LVM in /swap und / unterteilt (benötigt in diese Fall auch nur einen Schlüssel). Unter Debian Lenny funktioniert hiermit suspend to disk ohne weiteren Aufwand (bei meinem Notebook jedenfalls). Nur leider kann das "Aufwachen" doch relativ lange dauern (kommt aber sicher auch auf die vorliegende Hardware an).
Genau das habe ich geschrieben. Nur dass ich mich - wie der Artikel im Übrigen auch - auf Gentoo bezog.
OK, ich habe unterschlagen, dass man sich aus Gründen der Effizienz das Anlegen mehrerer verschlüsselter Partitionen sparen kann.
Ich verwende privat auf meinem Laptop auch die Methode ein cryptodevice zu öffnen und danach erst lvm2 zu starten. Nur startet im Baselayout 2 lvm direkt nach dem device-mapper und somit vor dmcrypt. Man muss also händisch in den Startprozess eingreifen um die Laufwerke verfügbar zu machen.
Wenn man weiß was man tut ist alles einfach, aber für den Anfänger übersichtlicher ist sicher die Methode in /etc/conf.d/dmcrypt die entsprechenden 2 Zeilen scharf zu schalten und die richtige Partition einzutragen. Nur funktioniert dann eben kein Hibernate.
Ich persönlich kann auf Hibernate verzichten. Wenn ich meinen Rechner ausschalte, dann habe ich eine Aufgabe abgeschlossen. Und booten kann mein Rechner schneller als "Aufwachen".
Nur leider kann das "Aufwachen" doch relativ lange dauern (kommt aber sicher auch auf die vorliegende Hardware an).
Suspend to Disk sollte man generell nicht ohne Veschlüsselung verwenden. Die Methode mit dem cryptoswap ist dabei wesentlich performanter, als das Verschlüsseln das Systemzustandabbilds, bevor es in die Swap-Partition geschrieben wird. Das hängt wahrscheinlich damit zusammen, dass letzgenannte Verschlüsselung im Userspace stattfindet.
Mal abgesehen davon, dass LRW durch XTS abgelöst wurde - einen Hash für LRW zu spezifizieren ist völlig sinnfrei, da er eh nicht verwendet wird: Das gibt es nur bei CBC-ESSIV und LUKS verwendet zur Schlüsselableitung sowieso SHA-1.
Von Sascha Wüstemann am Mo, 27. April 2009 um 21:08 #
Als Vorlage gab es eine vom Installer verschlüsselte Debian-Installation mit LVM im gecrypteten Container, also das ganze System in einer Partition (ja, der Debian Installer kann das, schon lange!). Das hatte mir so gut gefallen, dass ich es mir mit Gentoo nachgebastelt habe. Der besondere Vorteil darin liegt an der einzigen Passphrase, die man nur für den Container braucht und nicht für alle mount points je eines.
Erstellen ging flott, einzig eine initrd selbst erstellen für die cryptsetup Passphrase Abfrage und LVM Initialisierung hat einiges $uchmaschinen und Zeit beansprucht, war aber dann nicht weiter schwer.
Läuft super, bin echt schwer zufrieden damit und das Prinzip kann ich weiterempfehlen, besonders für Lappis. BTW: Für Produktionsumgebungen ist m. E. Gentoo eher sowieso nicht zu empfehlen, aber für zuhause zum rumspielen und Probleme lösen exzellent!
Das ist ja Bastelstunde hoch³ und eine Strafe. Ich kenne jetzt nur Truecrypt, damit sollte das doch aber gehen in einem viertel der Zeit und vor allem _ohne_ erstmal Stundenlang Befehlsketten auswendig zu lernen.
Solche Bastelaktionen sind eher ein "man kann es auch kompliziert machen, wenn man ein Kellerkind ist und selten an die frische Luft geht". Alle anderen nutzen dafür grafische Tools oder halt Distributionen wo man wenig basteln muss.
Es kommt dir nur deshalb so kompliziert vor, weil du keine Ahnung davon hast. Aber mach dir nichts daraus wenn es zu schwierig für dich ist. Dafür gibt es ja die Kinder-Distributionen, damit du mit Linux auch ein bisschen herumspielen kannst.
PS: Oh Mann, ich war ja auch mal ein überzeugter Gentoo-User ... aber wenn ich jetzt wieder sehe wie viel Arbeit das war. Jeder gute Installer macht es mit 3x mehr Optionen 1000x schneller.
Ich persönlich finde es frustrierend, wie sich bei Ubuntu Fehler von einer Version in die nächste schleppen, siehe Pulseaudio und Intel ICH HDA Audio, oder wenn bei einem Betatest (9.04) gemeldete Fehler nicht mal von Entwicklern kommentiert werden. Dafür gibt's Cloud-Computing!!!
Was nützt einem die schnelle Installation. Lieber Installiere ich mein System einmal 1-2 Tage und es läuft dann über Jahre, als in 30 Minuten und dafür alle 6-12 Monate.
Auf Arbeit?
Scheffe wo das erlaubt gehört entscheffet!
Das glaube ich nicht, Tim.
Schneller? definitiv!
Aber was sollen 3 mal mehr optionen sein? Grad bei gentoo hast du _SO GUT WIE ALLE_ Optionen, weil die installation eben nicht automatisiert ist. Installer sind dazu da vorgänge zu automatisieren, es ist also grade der sinn eines installers optionen wegzulassen die der distributor für unnötig hält und die installation dadurch zu beschleunigen.
Insofern erzählst einfach du unsinn. Ein Installer der _völlig_ flexibel alles erdenkliche während der installation erlaubt wäre die bash oder eine andere shell. Ganz einfach weil er nichts automatisieren könnte für den fall das der user während eines x-beliebigen vorgangs vllt doch das ein oder andere tun will was der distributor nicht vorgesehen hat. Und das gehört nun mal zur philosophie von gentoo, ergo ist die installation per kommandozeile die methode der wahl. Jegliche Installationsanleitungen sind halt eine Hilfe für neulinge um zurecht zu kommen, wenn man sich auskennt installiert man den krempel den man halt braucht ohne anleitung, so schwierig ist das nicht: festplatten partitionieren, basissystem drauf, dieses konfigurieren, den kernel backen, bootloader drauf, software die man will installieren, reboot fertig. Viele Distris automatisieren das, Gentoo halt nicht, eben wegen der Optionen die der User dabei hat. na, begriffen?
Btw, ich schrieb oben _SO GUT WIE ALLE_, weil man bei gentoo natürlich an einige vorgaben gebunden ist.. baselayout, portage und die dependancies wie python, usw usf. müssen sein damit die kiste läuft und sich gentoo schimpfen darf, aber dennoch gibt es meines erachtens nach nur noch LFS um ein nach flexibleres system zu haben.
Schwachsinn hoch drei
...oder sollen sich alle Foren, Blogs, Newsgroups usw mit DAUs füllen?
Also liebe Leute: Lienuks ist sowas von dermaßen und überhapt generell mehr als nur ein bisschen mindestens von Hinten dem Faß die Krone mitten auf'm Holzweg und das Pferd des Apothekers kotzt.
DAS wollt ihr nicht wirklich!
Alles klar?
Kindergarten...
Mounte mal eine AES256 verschlüsselte Partition! Du mußt das Kernelmodul bauen (dank Debian meistens kein Problem), in /etc/modules eintragen und dann kannst du die Partition mounten. Aber nur in der Konsole, weil KDE nicht in der Lage ist, dich nach dem Passwort zu fragen. Immerhin kannst du eine Zeile in die fstab setzen, sodaß auch Benutzer die Partition mounten können und du nicht jedesmal den vollen mount-Befehl brauchst. Für mich ist das alles kein Problem aber Komfort nenne ich das nicht?
Leute, ich schicke euch mal einen verschlüsselten USB-Stick. Wie wollt ihr auf den zugreifen? Findet ihr es wirklich angebracht, dass jemand, der nur schnell einen solchen Stick einstöpseln will, lange mount-Befehle lernt? Das meine ich. In der Standardsitiation ist alles kein Problem: Ich trage die verschlüsselte Partition in die fstab ein und kann sie mounten. Vielleicht gibt es Tools dafür. Wenn, dann sind sie schwer zu finden. Aber sobald ich vom Üblichen abweiche und z.B. mein USB-Stick verschlüsselt ist, komme ich so kein Stück weiter.
Ich weiß jetzt allerdings nicht ob TrueCrypt unter *BSD läuft.
cryptsetup ist eine Linux Lösung und die Einbindung in den Bootprozess ist _extrem_ Distributionsabhängig. Unter Ubuntu erkannte er zwar meine container, fragte aber ständig nach einem Passwort. Ohne meine Keys aus einem verschlüsselten Container bringt aber das beste Passwort nichts. Insofern ist Automount für meine verschlüsselten Datenträger komplett nutzlos.
Fazit:
Noch ist Verschlüsselung unter Linux ein Spezialgebiet. Man kann verschlüsselte Datenträger einer Distribution in eine andere Einbinden, es geht aber nur von Hand. Im Bootprozess ist diese Fähigkeit noch stärker eingeschränkt.
TrueCrypt wendet sich an diejenigen, die einfach etwas verschlüsseln wollen.
Gentoo spielt seine Stärken auf zwei Gebieten aus:
1. Lerneffekt
2. Sonderwünsche!
Wenn du mal versuchst ein System nur mit den nötigsten Paketen und einigen SVN versionen aufzusetzen stößt du mit anderen Distributionen schnell an die Grenzen und der Aufwand übersteigt den einer Gentoo Installation deutlich.
Die Einträge mit USE=static sollten aber eventuell in die package.use eingetragen werden sonst gibt es nach dem nächsten großen system-update ein böses Erwachen,
wenn die root-partition nicht mehr gelesen werden kann !
Danke vielmals für den Artikel
Aber im Prinzip reisst du einen wichtigen Punkt an - die statischen binaries werden nicht geupdated und schlummern im initramfs rum, irgendwann mal bekommt man ein problem wenn man nicht selbst dran denkt diese ab und zu mal aufzufrischen.
http://pastebin.com/f5a055320
Ich hoffe es ist einigermaßen brauchbar.
Ausgabe wenn ok:
gentoo-c2q bootsigcheck # ./bootsig --check
Checking image and boot device signature...
Comparing file signatures...
oder wenns nicht stimmt:
gentoo-c2q bootsigcheck # ./bootsig --check
((
Checking image and boot device signature...
Comparing file signatures...
the following file signatures didnt match:
/boot/tmp_mnt/grub/menu.lst:
/boot/tmp_mnt/grub/grub.conf:
COnt = continue with boot (you know what you do)
SHell = enter emergency shell (busybox)
RESTore = restore boot partition from boot image /boot/boot.img
BACKup = backup suspect boot partition to /boot/boot.img.suspect
BOot = reboot the system
HAlt = shutdown now without reboot
enter command:
gentoo-c2q bootsigcheck # ./bootsig --update
Update boot signatures...required:
backing up old boot image...
Creating image of boot partition /dev/sda2 as /boot/boot.img...
Creating new signature of /dev/sda2...
Adding signature of /boot/boot.img...
Checking signatures:
/dev/sda2: OK
/boot/boot.img: OK
Success!
(ich weiß, Spielkram...
)
aber sehr hilfreich
Danke vielmals !
Desweiteren, warum wird immer noch lrw empfohlen, dass bekanntlich eine potentiell ausnutzbare Lücke hat und mit xts bereits eine bessere/sicherere Technik existiert?
Was mich derzeit an der Verschlüsselung am meisten nervt, ist die Inkompabilität bei verschiedenen Systemen. Ein Austausch von Daten zwischen z.B. Linux *BSD ist auf einer einzelnen Kiste nicht wirklich sinnvoll möglich - LUKS und GEOM/GELI vertragen sich nicht und selbst bei den FS ist immer noch nichts ordentliches in Sicht(@Oracle, wenn das mit Sun klappt, ändert mal die ZFS-Lizenz).
"Da ist nur Zufälliger Müll drauf."
"Und wieso sind das genau so viele Bytes wie die zwei Filme hätten, die sie runtergeladen haben, wenn man sie verschlüsselte?"
Außerdem erschwert es die Forensische Analyse des vorhergehenden Inhalts der Platte.
Nicht umsonst wünschte ich, das Cryptodevice würde endlich kommen von dem ein Wissenschaftler mal gefaselt hatte (ca. 200 MByte/s echte Zufallszahlen). Das ganze mit PCIe Anschluss und das shredden von TB Platten macht wieder Spaß
Kleiner Tipp: Es reicht, wenn Du den Container z.B. mit Nullen vollschreibst; das geht wesentlich schneller.
Besser: Das schnelleren und schlechtere Randomdevice /dev/random statt /dev/zero oder /dev/urandom zum füllen nehmen.
Gruß Micha
Inwiefern?
- Was spricht dagegen für die Erstellung der ramdisk das genkernelpacket zu verwenden? Damit kann man luks, lvm und splashscreens mit einem Konsolenbefehl einbinden.
- Würde es für ein mehr an Sicherheit nicht Sinn machen, das Keyfile per GPG zu verschlüsseln? (afaik kann sogar die initramfs vom genkernel damit umgehen)
- Warum wird der swap nicht auch verschlüsselt? (geht ja mit dem Auskommentieren einer Zeile relativ einfach) (bin mir nur nicht sicher ob das hibernation noch funktioniert)
>- Würde es für ein mehr an Sicherheit nicht Sinn machen, das Keyfile per GPG zu verschlüsseln? (afaik kann sogar die initramfs vom genkernel damit umgehen)
Auf jeden Fall. Dann benötigt ein Angreifer etwas das du hast (USBstick) und etwas das du weißt (GPG Passwort). Nur spricht man dann meines Wissens nicht mehr von einem Keyfile sondern von einer von GPG gelieferten Passphrase.
>- Warum wird der swap nicht auch verschlüsselt? (geht ja mit dem Auskommentieren einer Zeile relativ einfach) (bin mir nur nicht sicher ob das hibernation noch funktioniert)
Die normale swap Verschlüsselung arbeitet mit Einmalschlüsseln. Hier ist eine Hibernation also so nicht machbar. Für Hibernation müsste swap wie eine verschlüsselte /home eingebunden werden. Ist technisch zwar machbar, meines Wissens aber im Baselayout (auch im 2.x) nicht vorgesehen.
Sollte der Artikel allerdings swap nicht verschlüsseln, dann ist er das Lesen nicht wert. Das ist das Erste was ein guter Crypto Artikel erwähnen sollte.
(14.1.)
cryptsetup -c blowfish -h sha256 -d /dev/urandom create swapfs /dev/sda2
Quellen:
- http://www.sidux.com/index.php?module=pnWikka&tag=FullDiskEncryptionTheDebianWay
- http://www.andreas-janssen.de/cryptodisk.html
OK, ich habe unterschlagen, dass man sich aus Gründen der Effizienz das Anlegen mehrerer verschlüsselter Partitionen sparen kann.
Ich verwende privat auf meinem Laptop auch die Methode ein cryptodevice zu öffnen und danach erst lvm2 zu starten. Nur startet im Baselayout 2 lvm direkt nach dem device-mapper und somit vor dmcrypt. Man muss also händisch in den Startprozess eingreifen um die Laufwerke verfügbar zu machen.
Wenn man weiß was man tut ist alles einfach, aber für den Anfänger übersichtlicher ist sicher die Methode in /etc/conf.d/dmcrypt die entsprechenden 2 Zeilen scharf zu schalten und die richtige Partition einzutragen. Nur funktioniert dann eben kein Hibernate.
Ich persönlich kann auf Hibernate verzichten. Wenn ich meinen Rechner ausschalte, dann habe ich eine Aufgabe abgeschlossen. Und booten kann mein Rechner schneller als "Aufwachen".
Suspend to Disk sollte man generell nicht ohne Veschlüsselung verwenden. Die Methode mit dem cryptoswap ist dabei wesentlich performanter, als das Verschlüsseln das Systemzustandabbilds, bevor es in die Swap-Partition geschrieben wird. Das hängt wahrscheinlich damit zusammen, dass letzgenannte Verschlüsselung im Userspace stattfindet.
Mal abgesehen davon, dass LRW durch XTS abgelöst wurde - einen Hash für LRW zu spezifizieren ist völlig sinnfrei, da er eh nicht verwendet wird: Das gibt es nur bei CBC-ESSIV und LUKS verwendet zur Schlüsselableitung sowieso SHA-1.
Erstellen ging flott, einzig eine initrd selbst erstellen für die cryptsetup Passphrase Abfrage und LVM Initialisierung hat einiges $uchmaschinen und Zeit beansprucht, war aber dann nicht weiter schwer.
Läuft super, bin echt schwer zufrieden damit und das Prinzip kann ich weiterempfehlen, besonders für Lappis. BTW: Für Produktionsumgebungen ist m. E. Gentoo eher sowieso nicht zu empfehlen, aber für zuhause zum rumspielen und Probleme lösen exzellent!
Ich kenne jetzt nur Truecrypt, damit sollte das doch aber gehen in einem viertel der Zeit und vor allem _ohne_ erstmal Stundenlang Befehlsketten auswendig zu lernen.
Solche Bastelaktionen sind eher ein "man kann es auch kompliziert machen, wenn man ein Kellerkind ist und selten an die frische Luft geht". Alle anderen nutzen dafür grafische Tools oder halt Distributionen wo man wenig basteln muss.
Aber mach dir nichts daraus wenn es zu schwierig für dich ist. Dafür gibt es ja die Kinder-Distributionen, damit du mit Linux auch ein bisschen herumspielen kannst.