(gelöst) cryptsetup

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
guennid

(gelöst) cryptsetup

Beitrag von guennid » 10.12.2017 21:40:48

Hmmm...

Irgendwie verstehe ich die Logik bei der Einrichtung einer verschlüsselten Containertatei via cryptsetup nicht. Ich komme von truecrypt und wollte eigentlich erreichen, dass ein User, der das Passwort für diesen Container kennt, ihn nach Passworteingabe irgendwo einhängen und dann wie jedes andere Verzeichnis nutzen kann.

Alles was ich bisher erreicht habe, war, dass ich als root bei der Anlage des containers ein solches Passwort vergeben musste, das anschließend scheinbar überhaupt keine Rolle mehr spielt! Root und nur root kann den container ohne irgend eine Passworteingabe jederzeit mounten und anschließend nutzen, also Dateien anlegen, verändern, löschen.

Nochmal hmmm...
Gehe ich recht in der Annahme, dass die vorgängige Anlage und spätere Löschung der Datei unter /dev/mapper, quasi ein Link auf den container, der springende Punkt bei der ganzen Sache ist: Die (Neu-)Anlage via

Code: Alles auswählen

cryptsetup luksOpen /Pfad/zum/container [dateiname unter /dev/mapper]
gelingt nur, wenn root das Passwort kennt. Und beim Mounten vergibt man dann als root dem User die nötigen Rechte auf das Mount-Verzeichnis? Löscht man nach getaner Arbeit und dem Aushängen des Mountpunktes als root wieder die Datei unter /dev/mapper, gibt es auf den eigentlichen Container keinen Zugriff mehr?

Noch anders formuliert: wird diese mapper-Datei nach Benutzung nicht gelöscht, kann sich zumindest root jederzeit ohne Passwort Zugriff verschaffen.
Zuletzt geändert von guennid am 12.12.2017 11:09:19, insgesamt 1-mal geändert.

DeletedUserReAsG

Re: cryptsetup

Beitrag von DeletedUserReAsG » 10.12.2017 23:19:31

Das „Aufschließen“ geschieht mittels cryptsetup luksOpen /pfad/zum/device name. Anschließend kannst du /dev/mapper/name wie ein normales Device nutzen, unter Anderem halt auch mounten. Möchtest du den Container wieder zumachen, gibt es dafür cryptsetup remove name – allerdings vorher aushängen nicht vergessen. Siehe auch die letzten Zeilen in meinem Codeblock im anderen Thread.

Das manuelle Löschen von Dateien unter /dev/ ist zu vermeiden. Für die Files unter /dev/mapper ist alleine der Devicemapper zuständig, der sollte nicht übergangen werden. Könnte sonst zu ganz seltsamen Effekten führen.

Benutzeravatar
spiralnebelverdreher
Beiträge: 1294
Registriert: 23.12.2005 22:29:03
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Frankfurt am Main

Re: cryptsetup

Beitrag von spiralnebelverdreher » 10.12.2017 23:39:42

guennid hat geschrieben: ↑ zum Beitrag ↑
10.12.2017 21:40:48
Alles was ich bisher erreicht habe, war, dass ich als root bei der Anlage des containers ein solches Passwort vergeben musste, das anschließend scheinbar überhaupt keine Rolle mehr spielt! Root und nur root kann den container ohne irgend eine Passworteingabe jederzeit mounten und anschließend nutzen, also Dateien anlegen, verändern, löschen.
Dem ist nicht so. Zum Öffnen des Conatiners brauchst du immer ein gültiges Passwort (es kann parallel mehrere geben wenn du das so anlegst). Das Öffnen eines Containers ist allen erlaubt, die den Befehl /sbin/cryptsetup ausführen dürfen. Wenn der Conatiner offen ist und ein Dateisystem enthält, muss dieses noch gemounted werden und dafür ist (wenn nicht anders konfiguriert) erstmal nur root berechtigt. Wenn root umounted und den Container nicht schließt, braucht es zum neunen Mounten dann auch kein Passwort (weil Container ja offen).

cryptsetup kennt die Option "open" zum Öffnen eines Conatiners und fragt nach dem Passwort, die Option "close" oder "remove" zum Schließen (ohne Passwortabfrage) und "status", welche dir das mapping anzeigt. Das mapping stellt die Verbindung des geöffneten Containers zu seinem Inhalt der.
In meinem System habe ich bspw. eine Partition namens "sdb2" mit luks verschlüsselt. Beim Öffnen wird bei mir dann ein /dev/mapper/sdb2_crypt erzeugt. Dieses kann ich dann bspw. in der /etc/fstab wie einen ganz normalen Devicenamen verwenden und festlegen, dass in /dev/mapper/sdb2_crypt ein ext4 Dateisystem wohnt und wohin es mit welchen Optionen gemounted werden soll.
guennid hat geschrieben: ↑ zum Beitrag ↑
10.12.2017 21:40:48
Nochmal hmmm...
Gehe ich recht in der Annahme, dass die vorgängige Anlage und spätere Löschung der Datei unter /dev/mapper, quasi ein Link auf den container, der springende Punkt bei der ganzen Sache ist: Die (Neu-)Anlage via cryptsetup luksOpen /Pfad/zum/container [dateiname unter /dev/mapper] gelingt nur, wenn root das Passwort kennt. Und beim Mounten vergibt man dann als root dem User die nötigen Rechte auf das Mount-Verzeichnis? Löscht man nach getaner Arbeit und dem Aushängen des Mountpunktes als root wieder die Datei unter /dev/mapper, gibt es auf den eigentlichen Container keinen Zugriff mehr?

Noch anders formuliert: wird diese mapper-Datei nach Benutzung nicht gelöscht, kann sich zumindest root jederzeit ohne Passwort Zugriff verschaffen.
Siehe oben, /dev/mapper/blablub wird durch cryptsetup open erzeugt und durch cryptsetup close geschlossen. Das Device /dev/mapper/blablub kann dann wie jedes andere blockorientierte Gerät verwendet werden: du kannst ein Filesystem anlegen oder aber auch mittels lvm physische und logische Volumes anlegen.

guennid

Re: cryptsetup

Beitrag von guennid » 11.12.2017 06:53:26

Ich danke für die ausführlichen Erläuterungen, entnehme ihnen, dass ich richtig liege damit, dass Anlegen und Löschen von /dev/mapper/irgendwas der "springende Punkt" bei der Benutzung eines cryptseup-Containers sind und danke niemand für den Hinweis, ein händisches Löschen von /dev/mappper/irgendwas tunlichst zu vermeiden. :wink:

Grüße, Günther

schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: cryptsetup

Beitrag von schwedenmann » 11.12.2017 08:50:17

Hallo


@guennei
dass Anlegen und Löschen von /dev/mapper/irgendwas der "springende Punkt" bei der Benutzung eines cryptseup-Containers
Das Anlegen und löschen geht nur per root und der bei cryptsetup vergebenen passphrase(n), die Benutzung, also die Berechtigung hängt dann vom Mountpoint ab. Wenn du /dev/mapper/blabla nach /home/user1 mountest, hat user1 Schreibrechte, auch wenn du den Container per root öffnen mußt und dort per mount mounten mußt (wenn kein fstabeintrag existiert).

mfg
schwedenmann

uname
Beiträge: 12043
Registriert: 03.06.2008 09:33:02

Re: cryptsetup

Beitrag von uname » 11.12.2017 09:34:37

Das ganze scheint mir ja mal endlich eine sinnvolle Anwendung für Debiansudo (eingeschränkte Befehle in /etc/sudoers) zu sein.

/etc/sudoers:

Code: Alles auswählen

Cmnd_Alias CRYPT = /sbin/cryptsetup luksOpen *, /sbin/cryptsetup luksClose *
username    ALL=NOPASSWD: CRYPT
Und dann als username:

Code: Alles auswählen

sudo /sbin/cryptsetup luksOpen ...
sudo /sbin/cryptsetup luksClose ...
Mount über /etc/fstab oder auch in
/etc/sudoers:

Code: Alles auswählen

username ALL = NOPASSWD: /bin/mount
username ALL = NOPASSWD: /bin/umount

Code: Alles auswählen

sudo /bin/mount ...
sudo /bin/umount ...
Achtung: Das ist eine Debian-Anleitung und hat nichts mit Ubuntu zu tun. Bei Ubuntu würde es auch ohne diese Einträge funktionieren, da über "sudo ..." jeder root-Befehl ausführbar ist.
Zuletzt geändert von uname am 11.12.2017 09:43:10, insgesamt 3-mal geändert.

schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: cryptsetup

Beitrag von schwedenmann » 11.12.2017 09:37:41

Hallo

oder siehe hier:

aus dem wiki-ubuntuuser zu cryptsetup
Leider ist es ziemlich umständlich und man braucht Root-Rechte dazu.

LUKS-Geräte können aber in GUI komfortabel per Maus-Klick eingebunden werden. Das Passwort kann dabei im Falle von GNOME im Schlüsselbund, bei KDE in der KDE Brieftasche hinterlegt werden, sodass LUKS-Geräte ohne extra Abfrage eingehängt werden können.

Unter GNOME kann man LUKS-Geräte mittels des GVFS (Gnome Virtual File System) einbinden. Das Einbinden ins GVFS erfolgt entweder über einen Dateimanager (z. B. Nautilus, Thunar oder PCManFM), über das graphische Tool Gigolo oder über die Kommandozeile mit dem Befehl gvfs-mount. Hierzu sind keine Root-Rechte und kein Eintrag in /etc/fstab erforderlich, und es muss auch nirgends ein SUID-Bit gesetzt werden. Die so eingebundenen LUKS-Geräte lassen sich auch ohne Root-Rechte wieder aushängen. Mehr dazu s. im Artikel gvfs-mount
mfg
schwedenmann

guennid

Re: cryptsetup

Beitrag von guennid » 11.12.2017 10:30:31

guennid hat geschrieben:dass Anlegen und Löschen von /dev/mapper/irgendwas der "springende Punkt" bei der Benutzung eines cryptseup-Containers
Warum fällt es eigentlich vielen Leuten so schwer, eine einfache Frage einfach mal mit "ja" zu beantworten und mögliche Zusätze dann zu formulieren, wenn man "nein" sagen muss. :wink: Ich habe hier doch gar nicht danach gefragt, wie man einen container anlegt, mountet, löscht.
schwedenmann hat geschrieben:Wenn du /dev/mapper/blabla nach /home/user1 mountest, hat user1 Schreibrechte, auch wenn du den Container per root öffnen mußt und dort per mount mounten mußt (wenn kein fstabeintrag existiert).
Interessant! Ich hätte jetzt gedacht, die Rechte muss ich in jedem Fall zusätzlich zuteilen. Werde ich testen.

schwedenmann
Beiträge: 5525
Registriert: 30.12.2004 15:31:07
Wohnort: Wegberg

Re: cryptsetup

Beitrag von schwedenmann » 11.12.2017 10:34:06

Hallo

@guennid
Interessant! Ich hätte jetzt gedacht, die Rechte muss ich in jedem Fall zusätzlich zuteilen. Werde ich testen.
Der Container verhält sich doch nicht anders, als eine beliebige Partition, die du in einem Mountpoint mit entsprechenden Zugriffsrechten mountest. da besteht dann nachher, für den Zugriff kein Unterschied zu einem Container.

mfg
schwedenmann

Benutzeravatar
spiralnebelverdreher
Beiträge: 1294
Registriert: 23.12.2005 22:29:03
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Frankfurt am Main

Re: cryptsetup

Beitrag von spiralnebelverdreher » 11.12.2017 15:57:20

schwedenmann hat geschrieben: ↑ zum Beitrag ↑
11.12.2017 10:34:06
@guennid
Interessant! Ich hätte jetzt gedacht, die Rechte muss ich in jedem Fall zusätzlich zuteilen. Werde ich testen.
Der Container verhält sich doch nicht anders, als eine beliebige Partition, die du in einem Mountpoint mit entsprechenden Zugriffsrechten mountest. da besteht dann nachher, für den Zugriff kein Unterschied zu einem Container.
Das ist genau der wichtige Punkt, den der schwedenmann da aufbringt: cryptsetup stellt dir nach dem Öffnen deine verschlüsselte Partition unter einem anderen Namen unverschlüsselt dar. Ab da ist alles wie vorher: Mount, Dateisystem, fstab, LVM, ...

guennid

Re: cryptsetup

Beitrag von guennid » 12.12.2017 09:41:53

Gehe ich recht in der Annahme, dass

Code: Alles auswählen

cryptsetup luksClose container
dasselbe bewirkt, wie

Code: Alles auswählen

cryptsetup remove container
? Ordnungsgemäß ausgeführt nämlich: das Löschen von container.
spiralnebelverdreher hat geschrieben:Das ist genau der wichtige Punkt
Aber nicht für mich. :wink:

TomL

Re: cryptsetup

Beitrag von TomL » 12.12.2017 09:51:20

guennid hat geschrieben: ↑ zum Beitrag ↑
12.12.2017 09:41:53
Gehe ich recht in der Annahme, dass

Code: Alles auswählen

cryptsetup luksClose container
dasselbe bewirkt, wie

Code: Alles auswählen

cryptsetup remove container
? Ordnungsgemäß ausgeführt nämlich: das Löschen von container.
Die Frage ist nur schwer zu beantworten, weil sie völlig unpräzise gestellt ist. Es gibt zwei Antworten:
1) Nein, luksClose und remove löschen den Container nicht als Datei.
2) Ja, luksClose und remove löschen den Mapper des Containers und entfernen den Key aus dem Kernel-Memory, die Datei "Container"ist davon unberührt.

"remove" ist wie "luksClose" ein Kompatibilitäts-Alias. Ich würde der besseren Assoziation wegen "luksClose" vorziehen, weil das eher dem enspricht, was wirklich passiert, oder noch besser einfach nur "close" gemäß man-page. ... wobei "remove" aus richtiger Perspektive betrachtet auch nicht grundsätzlich falsch ist.

Hth

guennid

Re: cryptsetup

Beitrag von guennid » 12.12.2017 10:09:32

TomL hat geschrieben:Die Frage ist nur schwer zu beantworten, weil sie völlig unpräzise gestellt ist.
Einigen wir uns auf "missverständlich"? :wink:

Mit container meinte ich die Datei "/dev/mapper/container (mir ist klar, dass ich DIESE Datei auch Rumpelstilzchen hätte nennen können), ich meinte nicht die "echte" Containerdatei mit den Daten.

Und nach meinen Beobachtungen existiert nach beiden von mir genannten Kommandos die Datei /dev/mapper/container/rumpelstilchen nicht mehr.

Ich bin halt nach niemands Hinweis weiter oben vorsichtig mit dem Entfernen von /dev/mapper/container und frage deswegen nach.

War's jetzt klarer? :wink:
Zuletzt geändert von guennid am 12.12.2017 10:33:40, insgesamt 1-mal geändert.

TomL

Re: cryptsetup

Beitrag von TomL » 12.12.2017 10:13:03

guennid hat geschrieben: War's jetzt klarer?
Ist unwichtig... ich hatte ja beide Möglichkeiten beantwortet.... wichtiger ist also, ob das jetzt klar ist :D

Antworten