Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Vollständige System Verschlüsselung außer boot (Gelesen 2297 mal)
|
|
Sebastian
Sr. Member
 Offline
Einträge: 488
|
 |
Vollständige System Verschlüsselung außer boot
« am: 20. Dezember 2019, 20:33:45 »
|
|
Hallo liebe Suletuxe,
Ich mache zurzeit meine ersten Arch Linux Erfahrungen, in einer VirtualBox um die Installation von Arch für mein Notebook zu erproben.
Da ich es wichtig finde mobile Geräte (Laptops, externe Festplatten, USB-Sticks etc.) zu verschlüsseln, damit die Daten vor dritten bei Verlust sicher bleiben. Kommt für mein Notebook nur eine voll System Verschlüsselung des Systems infrage.
Deswegen habe ich folgende Anforderungen bei der Installation von Arch
Anforderungen:
Die einhänge Punkte root,home und swap sollen verschlüsselt werden da diese private Daten enthalten. Nach dem Systemstart sollen diese durch Abfrage eines Passwortes freigeben werden.
Gebootet wird im UEFI Mode
Umsetzung:
Um dies zu bewerkstelligen, wollte ich LUKS und den LVM für die Verschlüsselung von root(/), home und swap einsetzten in dem ich ein Logical Volume für root(/) und ein LV für /home einrichte. Als swap wollte ich nur eine kleine Swap Datei (/swapfile) auf dem root LV verwenden da ich genug Arbeitsspeicher besitze und den hibernate Mode meines Notebooks nicht verwenden möchte.
Also habe ich nach dem Booten des Arch ISOs (stand: 01.12.2019) mir erst mal 3 Partitionen erstellt. (Festplatte war sauber)
| Partition Nr. | Typ | Größe | Verwendungszweck | | 1. | EFI (ef00) | 200 MiB | Partition für den Bootloader (Grub) | | 2. | Linux Filesystem (8300) | 5 GiB | Boot Partition für den Kernel und für das Initramfs
(Die Größe falls ich noch eine Rettungs- ISO darauf packen möchte) | | 3. | Linux LUKS (8309) | Rest der Platte | Partition für den LUKS Container. |
Dann die ersten zwei Partitionen formatiert:
mkfs.vfat -F 32 -n EFI /dev/sda1
mkfs.ext4 -L BOOT /dev/sda2
|
|
Und auf der dritten Partition den LUKS Container erstellt
cryptsetup luksFormat /dev/sda3 lukspart
|
|
Dann mittels LVM meine zwei LVs erstellt.
pvcreate /dev/mapper/lukspart
vgcreate vgluks /dev/mapper/lukspart
lvcreate -L 30G -n lvroot vgluks
lvcreate -l 95%FREE -n lvhome vgluks
|
|
5% habe ich für mich in der VG noch frei gelassen falls ich kurzfristig home snapshoten möchte für ein Backup (Der Snapshot ist nicht das Backup, sondern vom dem Snapshot möchte ich ein Backup machen).
Danach werden auch diese zwei LVs formatiert.
mkfs.ext4 -L ROOT /dev/vgluks/lvroot
mkfs.ext4 -L HOME -m 0 /dev/vgluks/lvhome
|
|
das -m bei der Formatierung der home Partition sorgt dafür das sich ext4 nicht standardmäßig 5% des Speichers reserviert.
Dann habe ich die Dateisysteme gemountet.
mount /dev/vgluks/lvroot /mnt
mkdir /mnt/{boot,home}
mount /dev/sda2 /mnt/boot
mount /dev/vgluks/lvhome /mnt/home
mkdir /mnt/boot/efi
mount /dev/sda1 /mnt/boot/efi
|
|
Jetzt noch die Swapdatei erstellen
fallocate -l 2G /mnt/swapfile
mkswap -L SWAP /mnt/swapfile
swapon /mnt/swapfile
genfstab -U /mnt >>/mnt/etc/fstab
|
|
Dann habe ich das Grundsystem wie im Arch Wiki beschrieben installiert.Und in die chroot Umgebung gewechselt.
pacstrap /mnt base base-devel linux linux-firmware grub vim ...
arch-chroot
|
|
Im System habe ich dann die Anpassungen wie im Arch Wiki beschrieben (locales einrichten usw.) durchgeführt.
Danach um das Initramfs für den Bootvorgang anzupassen musste ich noch ein paar HOOKS in der /etc/mkinitcpio.conf einrichten.
Die Infos hierfür habe ich auch im Arch Wiki gefunden.
Anpassungen an der /etc/mkinitcpio.conf
---------------------------------------
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck)
|
|
Danach habe ich noch die Konfiguration vom Bootloader angepasst und ihm ein paar Kernel Parameter übergeben, damit der Kernel systemd mit den richtigen Optionen startet.
cryptsetup luksUUID /dev/sda3
Um die UUID vom Luks Container zu erfahren
Anpassungen in der /etc/default/grub
------------------------------------
Die Folgende zeile habe ich angepasst
GRUB_CMDLINE_LINUX_DEFAULT="rd.luks.name=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX=lukspart rd.luks.options=none"
|
|
Die X sind nur Platzhalter da ich nicht noch mal meine UUID heraussuchen wollte.
Dann noch Grub auf die EFI Partition installiert. Und weil meine Virtualbox älter ist als Version 6.1 und noch unter einen UEFI Bug leidet musste ich die Installation etwas anders durchführen.
VirtualBox EFI Mode Arch Wiki
grub-install --efi-directory=/boot/efi --removable
grub-mkconfig -o /boot/grub/grub.cfg
|
|
Und zu guter Letzt noch den LVM installieren der auch gleichzeitig den Bau eines neuen initramfs triggert.
Danach konnte ich die chroot Umgebung verlassen alles unmounten und neu booten. Nach dem Neustart wurde ich nach meinem Passwort für den LUKS Container gefragt und nach Eingabe dessen hat mich mein neues Arch begrüßt.
Frage:
In Linux Mint gab es noch das Verzeichnis /etc/default/grub.d/ dort konnte man Dateien hinterlegen, die beim Generieren von /boot/grub/grub.cfg mit source eingelesen wurden.
Somit brauchte man die original /etc/default/grub nicht verändern und Änderungen bei einem Grub update blieben erhalten. Ist das unter Arch auch möglich?
|
|
 Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Vollständige System Verschlüsselung außer boot
« Antwort #1 am: 21. Dezember 2019, 08:08:31 »
|
|
Super Sebastian, dass Du das hinbekommen hast! Ich selbst habe keine hochgeheimen Daten auf meinem Laptop so dass ich bisher nur einen Container für wirklich wichtige Schen genommen habe und der Rest lief "normal".
Zu deiner grub-Frage: Es gibt auch unter Arch einen Ordner /etc/default/grub.d  . Wenn er nicht schon da ist, leg ihn einfach an.
LG
Andreas
|
| « Letzte Änderung: 21. Dezember 2019, 10:31:35 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 488
|
|
Re:Vollständige System Verschlüsselung außer boot
« Antwort #2 am: 21. Dezember 2019, 12:49:16 »
|
|
Super Sebastian, dass Du das hinbekommen hast! Ich selbst habe keine hochgeheimen Daten auf meinem Laptop so dass ich bisher nur einen Container für wirklich wichtige Schen genommen habe und der Rest lief "normal".
Zu deiner grub-Frage: Es gibt auch unter Arch einen Ordner /etc/default/grub.d . Wenn er nicht schon da ist, leg ihn einfach an.
LG
Andreas
|
|
Danke, mir macht Arch auch mehr und mehr Spass da man so wirklich mal sein System kennen lernt und man später nur das nötigste drauf hat.
Bei der Sache wegen der Verschlüsselung ich weiß halt meistens nicht vorher bzw. es ergibt sich oft auch erst später, ob eine Datei so wichtig ist das man sie Verschlüsseln muss. Und falls ich eine Datei unverschlüsselt mal abgespeichert hatte besonders in falle auf einer SSD ist es fast unmöglich diese Restlos vom Datenträger wieder zu entfernen ein reicht da leider ja nicht, um diese physikalisch von der Festplatte zu löschen. Und um diesen Umstand zu umgehen verschlüssel ich doch lieber gleich von Anfang an alles.
Und danke für den Tipp mit dem /etc/default/grub.d Verzeichnis. Ich dachte, dies würde nur zum Bau, der Menü Einträge benutzt werden. Zumindest sahen die Beispieldateien da drin so aus. Werde ich nachher mal ausprobieren, ob das geht.
Ich gebe dann Rückmeldung,
danke Dir
LG
Sebastian
|
|
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Vollständige System Verschlüsselung außer boot
« Antwort #3 am: 21. Dezember 2019, 14:38:18 »
|
|
Hallo Sebastian,
rm reicht zum sicheren Löschen definitiv nicht aus. Aber shred schon...
Und bezüglich grub Einstellungen kannst Du die nötige Konfiguration auch nach wie vor in /etc/default/grub packen.
LG
Andreas
|
| « Letzte Änderung: 21. Dezember 2019, 14:41:06 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 488
|
|
Re:Vollständige System Verschlüsselung außer boot
« Antwort #4 am: 21. Dezember 2019, 18:37:29 »
|
|
Hallo Sebastian,
rm reicht zum sicheren Löschen definitiv nicht aus. Aber shred schon...
Und bezüglich grub Einstellungen kannst Du die nötige Konfiguration auch nach wie vor in /etc/default/grub packen.
LG
Andreas
|
|
Noch einmal vielen Dank für Deine Hilfe Andreas.
Ich habe das es auch noch mal ausprobiert mit dem /etc/grub.d/ Verzeichnis. Das ist leider wie ich vermutet habe nur für die Templates der Menüeinträge gedacht. Da könnte, ich mir zwar ein Menüeintrag zurecht bauen mit den Kernel Parametern, aber wenn sich etwas bei einem Update ändern sollte, dann müsste ich wieder Hand anlegen.
Wie Du bereits sagtest, bleibt dafür nur die /etc/default/grub für die diese Art von Änderungen. Ich war es noch von Linux Mint gewohnt das aus dem Verzeichnis /etc/default/grub.d/ Dateien eingelesen werden, um nach dem Lesen der /etc/default/grub diese Werte zu überschreiben.
Soweit ich weiß funktioniert shred nur bei normalen HDDs zuverlässig. Bei einer SSD der Controller aber die Schreiboperatoren abfängt, um diese im Sinne der Haltbarkeit auf noch nicht so oft genutzte Blöcke aufzuteilen, kann nicht garantiert werden das genau der Block getroffen wird, wo die Datei gespeichert wurde.
Du glaubst nicht was man von gebrauchten SSDs an Daten wiederbeschaffen kann. Hier ein aktuelles Beispiel.
SSD mit Daten von Jugendamt und Zulassungsstelle bei eBay gefunden
Ich werde mich dann erst mal mit der /etc/default/grub zufriedengeben.
Ich rühre halt nur ungern original Dateien an. Habe auch irgendwo gelesen das pacman das irgendwie mitbekommt, wenn eine original Datei aus einem Paket verändert und bei einem Update glaube ich in .pacnew sichert.
Da ich mich mit pacman aber noch nicht so gut auskenne wollte ich nach Möglichkeit nicht so viele Originaldateien aus Pakten ändern.
Update: 22.12.2019
Habe noch mal nachgeschaut es wird nicht .pacsave, sondern .pacnew als Dateiendung genutzt von Pacman falls original Dateien verändert wurden und es neue Versionen der Dateien aus einem Paket gibt.
Das habe ich oben weiter korrigiert.
Pacman/Pacnew and Pacsave aus dem Arch Wiki
|
| « Letzte Änderung: 22. Dezember 2019, 11:51:44 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Vollständige System Verschlüsselung außer boot
« Antwort #5 am: 22. Dezember 2019, 09:08:38 »
|
|
Du hast Recht Sebastian. Bei SSDs funktioniert diese Technik nicht. Was da im Artikel beschrieben wurde, ist allerdings haarsträubend. Es sollte ja nicht eine einzelne Datei beseitigt werden (was nicht trivial ist), sondern die ganze Platte von Daten befreit. Und dafür kennen SSDs von Haus aus einen Mechanismus (secure-erase). Das war den Windows-Systemhäusern wohl unbekannt bzw. sie hatten keine Tools für Windows dafür...
Pacman erkannt veränderte Dateien, da kannst Du ganz beruhigt sein. Es wird bei keinem Update etwas von Dir überschrieben, und neuere Dateiversionen werden unter erweitertem Namen auf die Platte geschrieben. Ich habe übrigens die Dateien in /etc/default/ auch schon unter Debian fleißig für eigene Veränderungen genutzt - niemals ist es dabei zu einem Problem gekommen.
Man kann den /boot-Ordner auch auf einen USB-Stick legen, der bei einem boot immer im Gerät sein muss.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 488
|
|
Re:Vollständige System Verschlüsselung außer boot
« Antwort #6 am: 22. Dezember 2019, 12:16:38 »
|
|
Danke dir Andreas,
pacman lerne ich momentan echt lieben. apt unter Linux Mint hatte erst vor ca. 1-2 Wochen meine /etc/default/grub "überschrieben" bzw. weil es eine Zeile nicht so wiedergefunden hat einfach seine Einstellungen unten an die Datei angehängt was dafür gesorgt hatte das meine Einstellungen von oben überschrieben wurden. Mit pacman wäre das wohl nicht passiert. Durch diesen Umstand hatte ich auch erst von dem Verzeichnis /etc/default/grub.d/ unter Ubuntu Distributionen erfahren, das für eigene Änderungen an der /etc/default/grub config vorgesehen ist. Weil die Dateien darin nach dem einlesen der /etc/default/grub eingelesen werden.
Um nachträglich Dateien von einer SSD zu entfernen und nicht gleich die ganze Platte löschen zu müssen, dachte ich an den TRIM Befehl, um die ungenutzten Blöcke zu nullen. Aber nach dem Studium dieses Artikels, das dadurch die Verschlüsselung geschwächt werden kann, weil man dann zumindest in der Lage ist das verwendete Dateisystem zu erkennen und auch weiß, wo genau die verschlüsselten Daten auf der Platte liegen. Lies ich lieber davon ab, auch wenn es meine SSD auf Dauer etwas langsamer macht. Schnell genung ist sie mir aber immer noch.
|
|
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Vollständige System Verschlüsselung außer boot
« Antwort #7 am: 22. Dezember 2019, 15:38:05 »
|
|
Pacman ist schon ein tolles Tool. Ich finde es läuft reibungsloser als apt/dpkg.
Hast Du denn schon die AURs eingebunden (und mit yay gearbeitet)? Wenn Du erstmal siehst wie genial auf deinem Computer aus dem Quelltext Binaries gebaut werden, aus denen dann ein Paket erstellt wird und dieses dann "sauber" installiert wird - ich denke dann bist Du vollends überzeugt. Und das Ganze läuft echt stabil. Ich hätte es vor einem Jahr nicht gedacht - aber es läuft stabiler als der "Testing"-Branch von Debian.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 488
|
 |
Re:Vollständige System Verschlüsselung außer boot
« Antwort #8 am: 23. Dezember 2019, 10:06:26 »
|
|
Nein mit dem AUR und yay habe ich noch nicht gearbeitet. Wollte auch erst, wenn ich so weit bin ohne AUR helper arbeiten (yay ist glaube ich einer). Damit ich die Abläufe kennenlerne später, wenn ich die Abläufe verstehe, die so ein AUR helper durchführen müsste mache ich es mir bequemer.
Das Potenzial, das man mithilfe von pacman in der Lage ist, seine gebauten Pakete selbst zu verwalten erkenne ich jetzt auch schon. Deswegen bin ich schon überzeugt. 
Ich habe aber noch ein Problem, das wohl mit dem LVM zusammen hängen muss.
Und zwar nachdem ich das Grundsystem installiert und mir xfce4 darauf gepackt habe. Werden mir meine internen Dateisysteme auf dem Desktop angezeigt. Der Screenshot ist von einem BIOS deswegen fehlt hier noch die EFI Partition sonst wäre diese aber auch da.
Ich habe jetzt ein paar mal ein System aufgesetzt mit und ohne Verschlüsselung. Dieser "Fehler" tritt immer nur dann auf, sobald ich den LVM verwende.
Meine Vermutung ist deswegen das durch den LVM die Dateisysteme irgendwie als externe geführt werden. Vielleicht trifft deswegen irgendeine udev Regel nicht.
Hat da jemand vielleicht eine Idee?
Natürlich habe ich bei Xfce4 auch in den Einstellungen hereingeschaut da werden diese als entfernbare Datenträger geführt (was sie nicht sind).
Was ich auch nicht verstehe, denn in der /etc/fstab stehen alle Dateisysteme mit der UUID drin. Deswegen dürften die doch eigentlich nicht angezeigt werden, als entfernbare Datenträger.
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Vollständige System Verschlüsselung außer boot
« Antwort #9 am: 23. Dezember 2019, 13:39:37 »
|
|
Das hängt garantiert mit einer udev-Regel und LVM zusammen. Ich setze meine Systeme immer ohne Verwendung von LVM auf so dass mir das noch nicht über den Weg gelaufen ist. Ich denke hir kommst Du mit einer Suche im WIKI oder im Web weiter...
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 488
|
 |
Re:Vollständige System Verschlüsselung außer boot
« Antwort #10 am: 23. Dezember 2019, 14:06:47 »
|
|
Ich weiß zwar nicht genau woran es lag aber die Installation des Pakets gvfs das ich sowieso für das automatische einbinden und für den Papierkorb brauche, hat das Problem nebenbei gelöst. Die Dateisysteme sind vom Desktop verschwunden.
Wird wohl irgendwelche Regeln an udev übergeben haben.
|
| « Letzte Änderung: 23. Dezember 2019, 14:07:18 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
