Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Henrikx
10.12.2014 16:09:46

Danke.

TrialnError
10.12.2014 15:06:58
Henrikx schrieb:

Eine Art Audit habe ich bisher noch nicht über tomb gefunden.

Audit im Sinne zwar noch nicht, aber abgearbeitete CVEs oder sonstige Sicherheitskritische Punkte die bisher aufgetaucht sind kann man in den Issues finden.
https://github.com/dyne/Tomb/issues/150
https://github.com/dyne/Tomb/issues/162

Henrikx
09.12.2014 13:33:11

Ich weiß nicht ob es sinnvoll ist noch zu beschreiben wie z.B verschlüsselte ./thunderbird und ./mozilla Ordner erstellt werden können? Nachher geht da irgendwas mal schief und dann geht das "große Jammern" los. Besser wäre vielleicht auf die Manpage zu verweisen, ein wenig Kosmetik und den Artikel fertig stellen.

Henrikx
06.12.2014 19:50:48

Ja kenne ich, Danke.

Hatte ich aber noch nie länger im praktischen Einsatz. Werde ich jetzt nachholen. Bisher hatte ich EncFs im Einsatz. da stört mich allerdings das es kein Container ist. Vollverschlüsselung hatte ich "damals Anno Robinson" noch unter Debian im Einsatz. Lahmte aber den Laptop aus. Keine Ahnung wie das auf halbwegs aktuellen Computern jetzt aussieht.

Was mich stark wundert, das Tomb, selbst in diversen Linux-Blogs/Podcasts als gut gewertet wird. Habe bisher auch noch nichts wirklich negatives gelesen. Daher gehe ich wirklich davon aus..Einzelplatzsystem und Paranoiker sind die Zielgruppe.

Den Container selbst (tomb) und den separaten Schlüssel halte ich schon für eine sichere Sache, sofern ich das aus meiner Sich als Crypto-Neandertaler beurteilen kann.

Eine Art Audit habe ich bisher noch nicht über tomb gefunden.

Dirk
06.12.2014 18:28:22
Henrikx schrieb:

Was wäre denn eine vernünftige Truecrypt Alternative?

dm-crypt nebst entsprechender Tools kennst du? Das ist quasi der Standard, vor allem, weil dm-crypt eben nicht irgendein Zusatzzeugs ist, sondern direkt im Device Mapper, und damit schon im Kernel.

Henrikx
06.12.2014 11:24:28

Super. Danke.

Was wäre denn eine vernünftige Truecrypt Alternative?

Dirk
06.12.2014 06:27:30
Henrikx schrieb:

Falls wer eine bessere Formulierung hat, immer her damit.

Ich habe es gestern schon im Artikel als Hinweis vermerkt, da die Problematik wirklich nicht zu unterschätzen ist.

Henrikx
06.12.2014 00:22:21

Das könnte ich ja mit Hinweis auf diesen Thread einfließen lassen..

Nach bisherigem Kenntnisstand  sollte das Programm nicht auf Mehrbenutzersystemen verwendet werden.

Falls wer eine bessere Formulierung hat, immer her damit.

Dirk
05.12.2014 21:16:23
TBone schrieb:

Wenn das Skript als root läuft und dann sudo chown ausführt, aber in der sudoers.conf sudo für chown als root verboten ist, wird das verboten, obwohl das Skript als root läuft.

… was aber reichlich sinnlos wäre, weil das Script dann gar nicht mehr läuft smile

So oder so bleibt es sicherheitstechnisch sehr fragwürdig, und sollte nicht auf Mehrbenutzersystemen verwendet werden.

Dirk
05.12.2014 20:23:10
TBone schrieb:

Eventuell nutzt das Programm deswegen sudo, damit man so die Rechte von tomb feingranularer einstellen kann.

Pauschal Berechtigungen für ’nen ganzen Arsch voll systemkritischer Tools finde ich nicht sonderlich feingranular …

Henrikx schrieb:

Sollte ich den Artikel besser löschen?

Musst du wissen, ist ein Artikel über ein von dir genutztes Programm, oder ein Programm, dass du gern nutzen möchtest (denke ich mal – warum solltest du sonst auch einen Artikel darüber schreiben?). So lange der Artikel kein Nonsens ist, sage ich da nichts zu smile

Henrikx
05.12.2014 19:55:17

Sollte ich den Artikel besser löschen?

Dirk
05.12.2014 18:00:57
TBone schrieb:

Wenn 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?

Dirk
05.12.2014 16:57:35
Henrikx schrieb:

Tomb 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 schrieb:

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.

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?

Henrikx
05.12.2014 11:22:22

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.

Dirk
05.12.2014 02:19:58

Ä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.

Fußzeile des Forums

Powered by FluxBB