staging.inyokaproject.org

War ja auch nicht Ernst gemeint wie man am 😉 sehen kann. ☺

TOC ist drin - kann IMHO verschoben werden.

Sobald der Artikel verschoben wurde könnte ich den in die Verschlüsselungsartikel eintragen. Das sollte auch die einzige Sache sein, die noch bei Baustelle/System verschlüsseln/Installation mit Schlüsselableitung verändert werden müsste.

Gruß, unggnu

Verschoben, unter Skripte verlinkt.

unggnu schrieb:

P=`cat /dev/urandom | head -c 32` && echo $P | cryptsetup -c aes-xts-plain -s 256 luksFormat <Gerät> && echo $P | cryptsetup luksOpen <Gerät> temp && P='' && shred -vzn 0 /dev/mapper/temp && sleep 2 && cryptsetup luksClose temp 

Was ist denn das für ein Murx?

Das kann man auch schön schreiben und luks kann man sich sparen. 'head -c 32 /dev/urandom' ist zudem fragwürdig. Das produziert nämlich binär-Daten, nichts ASCII-artiges oder ähnliches, was eine Shell ohne Probleme verarbeiten kann. Und wie reagiert cryptsetup, wenn eines der ersten Binärzeichen zufällig als Newline interpretiert werden kann? Wird dann der Rest ignoriert? ( In deinem beabsichtigten Kontext ist das natürlich alles egal. Luks generiert ja auch aus schlechten Passwörter vernünftige Zufallszahlen als Schlüssel und danach wird der Header sowieso überschrieben. Man hätte also auch einfach "abcd" als Passwort nehmen können anstatt der Ausgabe von /dev/urandom... )

Für 'cat /dev/urandom | head -c 32' bekommst du zudem noch den beliebten "Useless use of cat" - Arward verliehen ☺

#!/bin/sh
DEVICE="<Gerät>" # anpassen
STATUSEXIT=0
if gpg -a --gen-random 1 66 | cryptsetup -s 256 -c aes-xts-plain create delete "$DEVICE" ; then
   if ! shred -vzn 0 /dev/mapper/delete ; then
	echo "Schreiben auf dem verschlüsselten Device fehlgeschlagen" >&2
	STATUSEXIT=1
   fi
   sync # für was soll das sleep gut sein? Wenn schon sync, oder auf was auch immer du warten willst.
   dmsetup remove delete 
else
   echo "Temporäres verschlüsselte Device konnte nicht angelegt werden" >&2
   STATUSEXIT=1
fi
exit $STATUSEXIT

Auch als häßlicher Einzeiler für alle, die in ihre Shell copy&pasten wollen ( ohne Fehlmedlungen )

sudo sh -c 'DEVICE="<Gerät>"; gpg -a --gen-random 1 66 | cryptsetup -s 256 -c aes-xts-plain create delete "$DEVICE"  && shred -vzn 0 /dev/mapper/delete && sync && dmsetup remove delete && echo "Ok"'

Red Radish schrieb:

Was ist denn das für ein Murx?

Du meinst sicherlich Murks. Wie auch immer, im Prinzip habe ich auf die schnelle ein Script zusammen gebastelt/kopiert ☺ was die von mir gewünschte Funktion ausführt. Und das tut es, auch wenn der Stil oder die Form ein Affront für Dich darzustellen scheint.

Mir war durchaus bewusst, dass LUKS nicht benötigt wurde, jedoch ist es genauso einfach und wie Du schon erwähnst bringt es ein paar Sicherheitsfeature mit, die nichts wirklich kosten, außer vielleicht ein paar Sekunden. Außerdem war ich mir dabei sicher, das es wie gewünscht funktioniert.

Das mit den Binärdaten war mir auch bewusst, aber warum auf lesbare Zeichen "warten", wenn es auch so geht. Das Passwort wird nie wieder gebraucht. Afaik würde ein Newlinzeichen einfach das Passwort verkürzen, was auch egal sein sollte. Ein festes Passwort zu verwenden würde trotz LUKS zu risikoreich sein imho.

Und ja, sleep wurde eingesetzt, weil ein direktes aushängen häufig nicht möglich ist. Wenn sync funktioniert ist es natürlich besser.

Wo wäre das Problem gewesen es ordentlich/freundlich zu formulieren, aber trotzdem danke für die Resonanz. Wenn es wie gewünscht funktioniert ist es sicherlich besser ☺

Hallo,

nun gut -und jetzt?

IMHO sollte Red Radish das Skript anpassen. Das Ergebnis ist das gleiche, der Weg ist schöner.

Da Skripte auch einen potentiellen Lehr-Charakter haben macht das auch noch mehr Sinn.

Gruß, noisefloor

Jup, klar soll seins verwendet werden, sobald das jemand getestet hat. Dazu ist doch die Wiki da.

Ich würde den Einzeiler bevorzugen, aber meinetwegen auch das Script. Die meisten Leute brauchen es nicht mehrmals, sondern nur einmal um ein oder zwei Partitionen zu überschreiben. Außerdem ist es nicht gerade ein Script, was man rumfliegen haben sollte, weil es ohne Rückfrage Geräte überschreibt.

Hallo,

Außerdem ist es nicht gerade ein Script, was man rumfliegen haben sollte, weil es ohne Rückfrage überschreibt.

Stimmt.

Der Einzeiler ist hat sehr schlecht lesbar...

Gruß, noisefloor

Also in seiner Kurzform finde ich es sehr gut lesbar und meine Bash-Script-Kenntnisse wurden hier ja schon auf den Punkt gebracht. 😀

Es scheint zu funktionieren - gpg meckert zwar über die Berechtigungen der gpg.conf, vermutlich weil gpg auf dem System noch nicht eingesetzt wurde (--no-permission-warning sollte die Fehlermeldung unterdrücken), aber sonst läuft es ohne Probleme nach einem kurzen Test. ). Ich bin nach wie vor für den Einzeiler aus den oben genannten Gründen. Sollte die Mehrzahl für das Script sein halt auch meinetwegen das.

Wer soll es eintragen, das rote Radieschen oder meine Wenigkeit?

Ok, das Problem mit gpg ist doch nicht so einfach. Es wird als root ausgeführt und meckert deswegen über die Dateiberechtigung des Nutzer-GPG-Ordners .gnupg. Sollte noch kein Ordner vorhanden sein, wird die Datei random_seed erstellt, die im Zuge dessen nur von root verändert werden kann.

unggnu schrieb:

Ok, das Problem mit gpg ist doch nicht so einfach.

Da ~/.gnupg im Nutzerverzeichnis liegt, kann der Nutzer die Dateirechte auch selbst ändern.

Aber es würde auch so gehen:

gpg --homedir /root/.gnupg -a --gen-random 1 66 | ....

Dann werden zumindest keine Dateien im Home-Verzeichnis des Users erstellt. Allerdings wird dann für root ein leerer Schlüsselbund angelegt...

Es geht aber noch einfacher und kürzer:

cryptsetup -d /dev/urandom  -s 256 -c aes-xts-plain create delete ...

Super, in der Version ist das gekauft, danke.

Aufgrund der Kürze wird glaube ich keine extra Variabel für das Gerät gebraucht. Außerdem sollte das lesen bei drei respektive vier Befehlen in Folge kein Problem sein.

Ich habe zwei Kleinigkeiten noch verändert. Einmal warum dmsetup, einen extra Befehl verwenden, wenn cryptsetup das auch erledigen kann, und laut manpage wird bei create standardmäßig eine Schlüssellänge von 256 verwendet, also können wir auf den Parameter auch verzichten.

sudo sh -c 'cryptsetup -d /dev/urandom -c aes-xts-plain create delete <Gerät>  && shred -vzn 0 /dev/mapper/delete && sync && cryptsetup remove delete' 

Ich habe das jetzt in den Artikel eingetragen.

Interessanterweise scheint das bei niedrigen GB-Zahlen nicht wirklich schneller als shred mit random zu sein, obwohl es mit annähernd Festplattengeschwindigkeit abläuft. Ich vermute mal, dass shred bei größeren GB-Zahlen langsamer wird sobald /dev/random leer ist und dadurch urandom ausgebremst wird oder es wurde in letzter Zeit der Algorithmus von shred verändert.

Als ich mein System eingerichtet habe, wirkte shred wesentlich langsamer, so das ich das hier genannte Verfahren eingesetzt habe. Im Zweifel schadet es aber nicht eine Alternative zu haben.

Es stört mich ein wenig, dass nicht nachgefragt wird, wenn man ein ganzes Device à la /dev/sda verwendet. Das ist bei shred aber nicht anders und sollte eine Partition davon eingehängt sein müsste es scheitern.

Das sieht doch schon mal viel eleganter aus - danke euch Beiden. ☺

Was mich gerade etwas wundert ist dass /dev/urandom als Keyfile funktioniert, obwohl es nicht terminiert - läuft das solange, bis zufällig eine Newline auftaucht?

Das wird doch auch bei der verschlüsselten Swap bzw. TMP-Partition ( Baustelle/Vorbereitung zur Teilverschlüsselung ) verwendet, eine der Gründe warum ich davon ausgegangen bin, dass die binären Zeichen kein Problem sein sollten. Ab einer gewissen Länge hört cryptsetup auf zu lesen.

From  a  key file: It will be cropped to the size given by -s. If there
       is insufficient key material in the key file, cryptsetup will quit with
       an error.

Vorher muss das entsprechende Gerät mit umount /dev/sda9 entbunden werden, sonst funktioniert's nicht.