OpenBSD auf dem Notebook ist eine feine Sache. Aber was ist, wenn das Gerät abhanden kommt, man es verliert oder es gestohlen wird? So schmerzlich der Verlust der Hardware auch ist, ein Gedanke drängt sich schnell auf: was passiert mit meinen Daten auf der Platte? Wer hat jetzt Zugriff darauf? Es ist nicht schwer, mit Hilfe von vnconfig(8) oder dem Paket cfs aus den Ports(7) einen sicheren Datensafe zu erhalten — aber hat man dort auch wirklich immer alle wichtigen Dinge drin?
In der folgenden Anleitung zeige ich einen Weg, wie man das Homeverzeichnis eines Nutzers mit Hilfe von OpenBSD-Bordmitteln sicher verschlüsseln kann.
Zum Einsatz kommt das Werkzeug vnconfig(8), mit dem virtuelle Block-Devices auf normale Dateien “gemappt” werden können. Das Problem hierbei ist nur, dass die Größe der Datei schon zu Beginn festgelegt werden muss, d.h. unser Homeverzeichnis des Users bekommt eine feste Größe die sich nachher nur durch Neuanlegen und umkopieren ändern lässt. Auf meinem Notebook ist das aber eher kein Problem, da ich der einzige Nutzer bin.
Alle Dateizugriffe müssen beim Lesen erst ent- und beim Schreiben verschlüsselt werden. Das führt zu einer etwas erhöhten Systemlast — und bei Notebooks zu etwas mehr Stromverbrauch bzw. geringerer Laufzeit im Akkubetrieb.
Der Einfachheit halber beziehe ich mich im folgenden Text auf einen neuen Nutzer “alice” in dessen Homeverzeichnis noch keine Daten liegen (also “frisch angelegt”).
Als erstes muss eine verschlüsselte vnode-Datei erstellt werden. Im folgenden wird mit Hilfe des Programms dd(1) eine 4GB große Datei angelegt. Anstatt /dev/zero nutzen wir /dev/arandom, damit unsere frische Datei von Anfang an wie “Datenmüll” aussieht. Als Nutzer root werden die folgenden Befehle ausgeführt:
# dd if=/dev/arandom of=/home/alice/.sparseimage bs=1m count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 238.319 secs (18021862 bytes/sec)
# vnconfig -ck svnd2 /home/alice/.sparseimage
Encryption key:
# echo -en »e 0\n0\ne 1\n0\ne 2\n0\ne 3\na6\nn\n0\n*\nw\nq\n« \
| fdisk -e svnd2 >/dev/null 2>&1
# echo -ne »a\na\n0\n\n4.2BSD\nw\nq\n« \
| disklabel -E svnd2 >/dev/null 2>&1
# newfs -q -m0 -otime /dev/svnd2a
/dev/svnd2a: 4096.0MB in 8388608 sectors of 512 bytes
21 cylinder groups of 202.47MB, 12958 blocks, 25984 inodes each
# vnconfig -u svnd2
Im Einzelnen wird eine 4GB große Datei mit Zufallsdaten gefüllt. Diese wird an das Device svnd2 gebunden und in diesem Device wird dann mit Hilfe von fdisk(8) ein OpenBSD-Slice angelegt. In diesem Slice wird dann mit disklabel(8) eine a-Partition angelegt und anschließend ein neues Dateisystem mit newfs(8) erstellt. Am Schluß entfernen wir noch die Verbindung von Device zu Datei mit “vnconfig -u”.
Ob im vorigen Schritt alles geklappt hat und das von uns verwendete Passwort (eigentlich handelt es sich hierbei um den Schlüssel für die Blowfish-Verschlüsselung) auch funktioniert, testen wir das Image:
# vnconfig -ck svnd2 /home/alice/.sparseimage
Encryption key:
# mount /dev/svnd2a /mnt
Wenn hier keine Fehler auftreten, dann war das Passwort korrekt und das Dateisystem ist ok. Ansonsten das Device mit “vnconfig -u svnd2” deaktivieren und den obigen Schritt wiederholen. Vielleicht war's ja nur ein Tippfehler im Passwort. Ansonsten Schritt 1. nochmal durchführen.
Nach dem Login über z.B. xdm(1) wird die Datei /.xsession aufgerufen, wenn vorhanden. In diese Datei legen wir die Kommandos, die zum automatischen mounten der verschlüsselten Datei nötig sind. Eine solche .xsession-Datei könnte so aussehen:
#!/bin/sh
if [ -e /.sparseimage ]; then
/usr/bin/sudo /usr/local/bin/crypthome
else
xterm
fi
exit 0
Als Beispiel für das Mount-Script crypthome kann dieses hier genommen werden. Nach dem Download kann es einfach nach /usr/local/bin kopiert und ausführbar gemacht werden.
Das Script startet nach dem Login ein XTerminal, in dem nach dem Passwort für das Image gefragt wird. Nach erfolgreicher Eingabe wird das Image nach /home/alice gemountet und dort nach der Datei .xsessions gesucht. Existiert diese Datei, wird sie ausgeführt. Das heißt, wir müssen in unserem Image auch noch eine solche Datei anlegen, in der der gewünschte Windowmanager gestartet wird. Da unser Image noch unter /mnt eingehängt ist, konnen wir dort eine .xsessions-Datei wie im folgenden Beispiel anlegen:
# cat /mnt/.xsession
#!/bin/sh
# wichtiger Eintrag
export DISPLAY=»:0.0«#
# Screensaver abschalten
xset s off
# Start des Windowmanagers
fluxbox
exit 0
Die Zeile export DISPLAY=”:0.0” ist hierbei ganz wichtig uns muss vorhanden sein. Im Beispiel wird der Windowmanager “fluxbox” gestartet. Wer KDE eher mag, kann statt dessen auch “startkde” eintragen.
Jetzt setzen wir noch passende Zugriffsrechte und hängen das Image aus:
# chown -R alice:alice /mnt
# chmod -R 770 /mnt
# umount /mnt
# vnconfig -u svnd2
Damit der Nutzer die Programme vnconfig(8), mount(8), umount(8) etc. auch nutzen kann, wird das Script crypthome über den Sudo-Wrapper gestartet. Hierfür muss noch ein Eintrag in der Datei /etc/sudoers gemacht werden:
# visudo
…
alice ALL = NOPASSWD: /usr/local/bin/crypthome
…
Alice kann sich nun am System anmelden und sollte zur Eingabe des Passworts aufgefordert werden. Wenn mit dem Passwort das Image entschlüsselt werden kann wird das Image geprüft (fsck(8)) und dann gemountet. Alles, was Alice dann in ihrem Homeverzeichnis tut wird nur verschlüsselt gespeichert. Loggt sie sich aus oder ist der Strom weg kommt man ohne das Passwort nicht mehr an die Daten ran — auch wenn man die Festplatte ausbaut wird man nur “Datenmüll” finden.
Das hier in der Anleitung benutzte Script ist sehr einfach gehalten und funktioniert auch nur bei Anmeldung am X11-System. Mit etwas Anpassung kann man das aber auch für Konsolen-Logins hinbekommen …
»Thou shalt study thy libraries and strive not to reinvent them without cause, that thy code may be short and readable and thy days pleasant and productive.«