luksSuspend des rootvolumes vor suspend to ram?

Hi

ich habe einen LUKS-container, welcher ein LVM-PV enthält, welcher eine VolGroup bildet, welche swap und mein / enthält. keine weiteren dateisysteme.

jetzt möchte ich vor einem suspend-to-ram durch pm-suspend meinen container wieder verriegeln, also cryptsetup luksSuspend aufrufen. das geht soweit auch
allerdings will ich luksResume auch aufrufen, und das wird schwierig, wenn / momentan nicht zugreifbar ist

deshalb hab ich mir überlegt, dass ich /bin, /sbin und /lib in ein tmpfs kopiere, und dann die verzeichnisse dieses tmpfs über /bin, /sbin und /lib mit mount --bind drübermounte. mit dem ziel, dass cryptsetup eben nicht von de rplatte gelesen werden muss, sondern aus dem unverschlüsselten arbeitsspeicher.

als ich aber einen trockenlauf gestartet habe, hats aber leider nicht geklappt. luksSuspend hat getan was es soll, aber luksResume hat blockiert und wollte nicht starten. ergo konnte ich das ganze nimmer entsperren -> fail

was hab ich falsch gemacht? eigentlich dürfte luksResume doch nicht blockieren, da es aus dem ram gestartet wird, oder?

hoffe ihr könnt mir da helfen. oder mir ne andere möglichkeit sagen, wie man das hinkriegt

lg
flo

flo(h) schrieb:

oder mir ne andere möglichkeit sagen, wie man das hinkriegt

Zum Vergrößern anklicken....

root und swap komplett verschlüsselt dann, suspend to ram oder noch besser suspend to disk, irgendwo beisst sich da mal die Katze in den Schwanz.

für alle die hyperwichtige Dateien auf mobilen Geräten haben, oder die der Meinung sind unterhalb von /usr /lib /bin und /sbin gibt es Dateien die unbedingt verschlüsselt gehören und der Bootloader müsste am besten auch noch verschlüsselt werden, FDE Laufwerke zb

robi

robi schrieb:

flo(h) schrieb:

oder mir ne andere möglichkeit sagen, wie man das hinkriegt

Zum Vergrößern anklicken....

root und swap komplett verschlüsselt dann, suspend to ram oder noch besser suspend to disk, irgendwo beisst sich da mal die Katze in den Schwanz.

Zum Vergrößern anklicken....

öhm, und wo bitte?

suspend-to-disk ist ja mal absolut kein problem bei einem verschlüsselten system. der ram-inhalt wird halt einfach in die swap geschrieben, die ja transparent verschlüsselt wird. und beim aufwachen muss ich der initrd das passwort sagen, woraufhin sie die swap anguckt, sieht "ui, wir wollen resume", und das dann auch tut.

und s2ram habe ich mittlerweile auch hinbekommen:
für alle interessierten hier die vorgehensweise:

ein tmpfs irgendwohinmounten. darin ein verzeichnis "foo" erstellen.
/bin, /sbin und /lib (/lib/modules ist NICHT nötig und frisst vergleichsweise viel platz) nach foo kopieren
/dev, /sys, /proc nach foo/{dev,sys,proc} hängen mittels mount --bind
in foo hinein-chrooten.

dann kann man in tty1 folgendes machen: sync && cryptsetup luksSuspend enigma && echo mem > /sys/power/state
(es ist wichtig, dass das unmittelbar nacheinander ausgeführt wird. denn wenn in der zwischenzeit etwas anderes versucht, dateien zu ändern, wird der sync()-aufruf, den echo mem >... zwangsläufig absetzt, das system einfrieren, da /dev/mapper/enigma ja blockiert dank luksSuspend)
nach dem aufwachen dann cryptsetup luksResume enigma, und alles ist in ordnung
(wichtig: NICHT in Xorg ausführen, sonst freeze)

und "in schön" kann man das dann in die /usr/sbin/pm-suspend packen:
einfach die do_suspend() funktion neudefinieren: "das tmpfs anlegen", in foo/ eine skriptdatei anlegen, welche "sync && cryptsetup... && echo mem... && luksResume..." macht, und dann das ganze folgendermaßen ausführen:
openvt -sbw -- chroot /tmp/das_tmpfs/foo /bin/bash /meinskript.sh

openvt switcht automatisch auf ein freies tty, startet dann das skript in einer chroot, und nach beeindigung desselben switcht es wieder auf das ursprüngliche tty zurück.

natürlich kann man den teil von "luksResume" etwas aufhübschen: mein laptop z.B. braucht einen quirk, um die bildschirmbeleuchtung von hand auszuschalten, und die geht erst wieder an, NACHDEM man das passwort eingegeben hat (sonst ist /usr/sbin/vbetool nicht zugreifbar). while ! /lib/cryptsetup/askpass | cryptsetup luksResume enigma --key-file=-; do echo -e '\a'; done piept wenigstens vor der passworteingabe. so kriegt man mit, ob ,man sich vertippt hat, oder das system sich anderweitig erschossen hat.


nochmal was zur sicherheit:
ich halte diese lösung schon für ausreichend sicher. die einzigen möglichkeiten, ans passwort zu kommen, sind folgende:

• laptop im laufenden betrieb stehlen (s2ram oder s2disk reicht NICHT; bei s2ram sind allerdings noch einige daten aus dem cache rekonstruierbar). es ist unmöglich, sich gegen diesen angriff zu schützen.
• unbemerkt (!) in mein haus/zimmer einbrechen, und entweder eine überwachungskamera, einen hardwarekeylogger anbringen oder meine initrd manipulieren (wenn ich es merke, kann ich je nach paranoiafaktor den bootloader+initrd austauschen, das laptop untersuchen oder das laptop nie wieder für sensible informationen verwenden, stattdessen ein neues, sicher unkompromittiertes kaufen)
• unbemerkt sich remote-root-zugriff zu meinem laptop verschaffen und die initrd manipulieren. (in dem fall kann man aber auch gleich die daten via netzwerk kopieren, ohne den umweg über einen keylogger in der initrd; schutz ist halbwegs möglich.)
• rubber-hose-kryptoanalyse

ein angreifer müsste also entweder irrsinnigen aufwand treiben, um unbemerkt an meinem system herumzumanipulieren, oder mich entführen. und SO wichtig bin ich glaub ich nicht. (das wäre was anderes, wenn ich weltberühmter atomforscher o.Ä. wäre)

und sinnlose paranoia ist das auch nicht: all diese sicherheitsmaßnahmen stören mich nicht. ob ich jetzt ein bios/screensaver-passwort (gegen "ui gib mir doch mal dein laptop"-menschen) eingebe oder ein festplattenpasswort ist egal. ob ich nach dem s2ram meine sitzung wieder entsperre oder die festplatte wieder freischalte, macht auch keinen unterschied. (das wäre was anderes, wenn ich nurnoch von einem schreibgeschützten usb-stick booten würde, nachdem ich verifiziert habe, dass niemand mein bios manipuliert hat, und danach im 5-minuten-takt das plattenpasswort auffrische (zum schutz gegen laptopklau und anschließenden RAM-dump))

es ist wahr, es mag einen tick zu sicher sein für mich. aber wer will freiwillig an sicherheit sparen, wenn es keine usability-einbußen mit sich bringe?

mfg
flo