Tomb :: File Encryption on Linux
Ich habe dieses großartige Tool für mich entdeckt und meine es sollte in die Wiki.
Nach meiner Meinung, mehr als eine gute Alternative für Truecrypt (Linux only).
Es gibt schon einen Artikel bei wiki.archlinux.org, der könnte als Vorlage dienen.

Frage : Hat jemand Tomb schon länger im Einsatz und kann etwas dazu hier schreiben. Benutzbarkeit, Zuverlässigkeit, Positiv, Negativ?

Falls.... kein anderer vorhat den Artikel zu schreiben, der positive Eindruck über das Tool nicht täuscht, würde ich in den nächsten Tagen, sobald ich mit mpv fertig bin, der Artikel anfangen. (was für ein Satz) 😉
Ich habs mal nach Tomb verschoben 🙂
Danke!

Mag sich zwar lustig anhören, aber ich war mir nicht sicher, ob der Zusatz : File Encryption on Linux zum Namen gehört. :rolleyes:
Henrikx schriebMag sich zwar lustig anhören, aber ich war mir nicht sicher, ob der Zusatz : File Encryption on Linux zum Namen gehört. :rolleyes:
Und selbst wenn: Es steht auch KDE, und nicht „KDE Software Compilation 4“ im Wiki, oder GIMP und nicht „GNU Image Manipulation Program“ 🙂

Das Projekt liest sich ein bisschen wie ein umständlicher Weg, LUKS zu nutzen *g*
🙂

Eigentlich ist es damit ziemlich einfach verschlüsselte Container anzulegen.
In wie weit es sicherer ist als z.B. EncFs kann ich nicht sagen..
Ahoi,


das tool scheint interessant. Nur ist die Handhabung etwas unglücklich. Ich bin ja geneigt als normaler User Daten zu verschlüsseln, aber wenn ich allein für das Öffnen das Containers ungelogen 12 mal für sudo das Passwort
eingeben muss (zum Schließen 3 mal), dann ist doch da irgendwas faul. Handlich ist anders....gibts da ausser alles als root zu machen einen Trick, wie man tomb flüssig nutzen kann? nur tomb in der /etc/sudoers freizugeben wird nicht reichen, da allerhand mount-gedöns ausgeführt wird.
tomb open -f safe.tomb -k key 
tomb  .  Grab safe.tomb wird geöffnet
tomb  .  Gültige tomb Datei gefunden: ./safe.tomb
tomb  .  Schlüssel ist gültig
tomb  .  Mountpoint nicht angegeben, /media/safe.tomb wird benutzt
tomb (*) Öffne safe.tomb auf /media/safe.tomb
[sudo] password for lk: 
[sudo] password for lk: 
[sudo] password for lk: 
tomb  .  Dieses Grab ist ein gültiges LUKS verschlüsseltes Gerät.
[sudo] password for lk: 
tomb  .  Verschlüsselung "aes" im Modus "xts-plain64:sha256" und der Hashfunktion "sha1".
tomb  .  Ein Passwort ist zur Benutzung des Schlüssels key erforderlich
tomb  .  Passwort OK.
[sudo] password for lk: 
[sudo] password for lk: 
tomb (*) Entsperren erfolgreich von safe
tomb  .  Dateisystem kontrollieren mit /dev/loop1
[sudo] password for lk: 
fsck von util-linux 2.25.2
safe: sauber, 16/25168 Dateien, 8852/100352 Blöcke
[sudo] password for lk: 
[sudo] password for lk: 
[sudo] password for lk: 
[sudo] password for lk: 
[sudo] password for lk: 
tomb (*) Erfolgreiches Öffnen von safe.tomb auf /media/safe.tomb
tomb  .  Letzer Besuch von lk(1000) von /dev/pts/1 auf edge
tomb  .  am Mi 03 Dez 2014 11:44:04 CET


irgendwie ist da aufs3 wesentlich handlicher, wenn auch nicht so portabel....wobei, dann ja auch erstmal der andere Rechner tomb + Abhängigkeiten installiert haben muss....

/L-K
Ich muss mal schauen.
Im Moment durchforste ich noch das Web nach Tipps und Tricks. Ich selbst nutze so gut wie nie sudo.
Interessant finde ich die Option den Schlüssel in einem Bild zu verstecken
tomb bury -k /path/to/key /path/to/file.jpg

Was ich noch nicht ganz verstehe sind HOOKS

https://github.com/dyne/Tomb/wiki/Advancedfeatures
@linux-ka
So ich habe jetzt alles 10 Mal durchgespielt..
So oft sudo wie bei dir, habe ich nicht..
@Henrikx

Dann hast du aber in deiner /etc/sudoers config einiges freigegeben, oder?
Ja, habe ich.

Findest du die Anleitung bis jetzt (Ist ja noch nicht fertig)verständlich?
An der Handlingreihenfolge an sich gab es bisher keinen Zweifel. Zu deinem Artikel: den eigentlichen Arbeitsablauf deckt dieser bisher ab.
Klasse wäre es, wenn du einen Weg dokumentieren könntest, wie tomb letztlich vom user passwortfrei genutzt werden kann. Reicht es wirklich aus tomb in der sudoers config freizugeben? Das Skript ruft eine ganze Menge via sudo auf: mkfs.ext3, losetup, mkdir, file, dmsetup, cryptsetup, umount, fsck, tune2fs, mount, chown. chmod, e2fsck, resize2fs.
Wenn man das alles noch in die sudoers config reinfriemeln muss, dann wäre das schon nervig...
OK ich schau mal ob das geht...
Ähm … Ich hab mir das gerade mal angeschaut.

Das Ding erwartet ernsthaft, dass User mittels sudo unter anderem mount, umount, fsck, chown, chmod und noch ein paar andere systemkritische Befehle ausführen dürfen.

Das ist ein einziges, riesiges Sicherheitsloch auf Mehrbenutzersystemen.
Ich glaube (zur Zeit) auch nicht, dass Tomb im Ursprung für ein Mehrbenutzersystem gedacht war.
Paranoia war sicher mit einer der Väter.

Container plus getrennter AES256 Schlüssel. Dieser auch noch per Passwort gesichert, ist schon mal eine Hausnummer.
Schlüssel per Steganographie verstecken, ebenfalls. Netzwerkfähig ebenfalls (Cloud)

Tomb verlangt explizit root laut den Howtos. Auf einem Einzelplatzrechner kann das als Sicherheitsfunktion gewertet werden.
Es kann aber auch sein, dass ich das Programm noch nicht wirklich verstehe und du Recht hast. Falls ja, kann man das dem Artikel beifügen, oder den Artikel löschen.
Da es keine weiteren verständlichen!! Anleitungen im Netz gibt, muss ich mir die das meiste (leider ) erarbeiten und kann noch gar kein abschließendes Urteil dazu sagen.
Die von dir aufgeführten Befehle werden ja per Script aufgerufen. Mount geht ja automatisch auf /media/secret.tomb/. In wie weit das zu ändern ist, weiß ich z.Z. noch nicht.
Henrikx schriebTomb verlangt explizit root laut den Howtos. Auf einem Einzelplatzrechner kann das als Sicherheitsfunktion gewertet werden.
Das Script selbst ruft an mehreren Stellen sudo auf.
$ grep sudo tomb | sed s/".*\(sudo [0-9a-z\.]*\).*"/"\1"/g | uniq
sudo mkfs.ext3
sudo losetup
sudo mkdir
sudo file
sudo dmsetup
sudo losetup
sudo gpg
sudo cryptsetup
sudo umount
sudo cryptsetup
sudo fsck
sudo tune2fs
sudo mkdir
sudo mount
sudo chown
sudo chmod
sudo umount
sudo mount
sudo cryptsetup
sudo e2fsck
sudo resize2fs
sudo cryptsetup
sudo umount
sudo cryptsetup
sudo losetup
sudo 
So ein Script (bzw. so viele sudo-Berechtigungen für so viele Systemkritische Programme), sollte man nicht vergeben. Schon gar nicht für ein Script, das „aus Sicherheitsgründen“ geschaffen wurde.
Henrikx schriebDie von dir aufgeführten Befehle werden ja per Script aufgerufen. Mount geht ja automatisch auf /media/secret.tomb/. In wie weit das zu ändern ist, weiß ich z.Z. noch nicht.
Nun, gemäß Script muss für die genannten Befehle die Möglichkeit bestehen, dass der User sie per sudo aufrufen kann. Aus Bequemlichkeitsgründen wohl ohne Passwort (sonst artet das in eine Passwort-Eingebe-Orgie aus *g*) – aber das ist hier zweitrangig, Tatsache ist, dass der User die Befehle per sudo ausführen müssen kann.

Was hindert den User daran, sudo umount / einzugeben? Oder chown mallory:user /root? Oder sudo mount -oloop /home/mallory/hacking.iso /usr/bin? Oder einfach nur mkfs.ext3 /dev/sda1, um zu testen, ob der Administrator für /dev/sda1 wirklich ein Backup hat? *g* … Oder die ganzen Befehle in eigenen Scripts anderweitig zu verwenden?
TBone schriebWenn das Script "tomb" mit sudo aufgerufen wird, werden alle darin enthaltenen Befehle als root ausgeführt. Deswegen braucht man doch nur dieses eine Skript per sudo zu erlauben.
Da ich sudo prinzipiell ablehne, kann ich im Detail dazu natürlich nichts sagen, aber führt su -c 'sudo umount /' den Befehl umount / über sudo aus, obwohl umount nicht in der sudoers-Datei eingetragen ist?

Wobei es effektiv ja sudo sudo XYZ ist, aber die Frage bleibt, wird XYZ ausgeführt, obwohl sudoers leer ist?
Sollte ich den Artikel besser löschen?