Zuerst einmal sollte man sich überlegt haben welche Art Raid man benötigt.

Ich bevorzuge für die Systemplatte ein Raid 1 (Spiegelung)

Für Datenplatten nutze ich ein Raid 5 aus mindestens 3 Festplatten oder Partitionen.

mdadm - -create - -level=1 /dev/md0 /dev/sda2 /dev/sdb2

Mit diesem Befehl erzeugt man ein Raid 1 mit 2 Partitionen

mit dem Befehl: mkfs.ext3 /dev/md0 erzeugt man ein dateisystem auf dem frisch generierten Raid 1

mount /dev/md0 /raid1

 Mit diesem Befehl hängt man die Raid-Partition auf dem Mountpunkt /raid1 ein

Damit kann man das Raid benutzen.

Für ein Raid 5 funktioniert das genau so, nur das man 3 Platten angibt.

mdadm - -create - -level=5 /dev/md1 /dev/sdc1 /dev/sdd1 /dev/sde1

Hiermit wird ein Raid 5 Verbund aus 3 Festplatten (Patitionen) erzeugt.

danach wie oben beschrieben das Filesystem erzeugen und danach zur Nutzung in das System einhängen.

Viel Spass

Die weiteren Anwendungsmöglichkeiten sind das automatische Sperren des Bildschirms beim entfernen der Smartcard (Datei -> sc-screensaver-ctrl), sowie der Einsatz der Smartcard für teilweise oder vollständige Verschlüsselung von Partitionen. Hier ist noch etwas experimentieren angesagt, da es kaum brauchbare Anleitungen dafür gibt und die verwendeten Scripte (Debian) für root-fs Verschlüsselung fehlerhaft sind. Die Erfahrungen werden wir bei Gelegenheit nachreichen.

Update: Erfahrungsbericht mit PinPad-Readern

Smartcards unter Linux - die unendliche Geschichte

Langsam aber sicher geht es vorwärts mit den Möglichkeiten, Smartcards auch unter Linux einzusetzen. Dabei genügt es nicht, dass die wichtigsten Anwendungen diese unterstützen, auch die richtige Kombination aus Karte und Kartenleser ist zu beachten. In dem begrenzten Markt von Smartcard-Herstellern und den dabei verwendeten Chips und Kartenbetriebssystemen sind die passenden Linux-Module meist erst mit einiger Verzögerung vorhanden und das auch nur bei genügender Verbreitung der Karten und der Offenlegung der Spezifikationen.
 Das zentrale Linux Projekt 'Opensc' listet daher viele Karten als unterstützt auf, die schon nicht mehr erhältlich oder nur noch vereinzelt zu kaufen sind. Die einzige mir im Moment bekannte Karte, die noch laufend produziert wird und vollständig mit Linux administrierbar ist, ist die Feitian-PKI-Card. Die ebenfalls noch produzierten Siemens Karten mit CardOs lassen sich nur dann mit Linux bearbeiten, wenn sie unter einem anderen Betriebssystem zunächst umprogammiert werden, der dazu nötige Kartenbefehl wird von Siemens geheimgehalten und kann daher nicht in offene Linux-Programme integriert werden.
 Neben den Karten sind auch die Lesegeräte sorgfältig auszuwählen. Zur Zeit sind gerade mit der Feitian Karte nicht alle Leser kompatibel, obwohl sie als 'von Linux unterstützt' aufgelistet werden. Es ist mit eigenen Versuchen der passende herauszufinden. Bei mir laufen folgende Leser mit der Karte: SCM SCR 35xx (kein PinPad), SCM SCR 532 (Kl.2 PinPad), Gemalto PC Pinpad (Kl.2 PinPad und Display). Jeder Leser kann mit der Feitian Karte arbeiten, d.h. Löschen, Beschreiben und Lesen, PIN verifizieren und ändern. Es hat etliche Tests gegeben, die überraschende Ergebnisse brachten und auf noch vorhandene Fehler in der Treibersoftware hindeuten. Da ich zunächst nur den Leser ohne PinPad benutzte, sind meine bis dahin benutzten Karten damit initialisiert worden, die später hinzugekommenen PinPad Leser konnten die PINs derartig beschriebener Karten jedoch nicht mit ihrem eigenen PinPad verifizieren, so dass ich zunächst annahm, dass diese Leser für die Karte ungeeignet wären. Nach Deaktivierung der PinPads waren die Karten jedoch ansprechbar und weitere Tests folgten. Das wahrscheinlich ein Bug im Treiber die eigentliche Ursache sein könnte, fand ich zufällig, als ich eine Testkarte statt mit einer 7-stelligen PIN nur mit einer 4-stelligen PIN benutzte. Diese funktionierte auf allen Lesern einwandfrei und ließ mich verschiedene PIN-Längen mit allen Lesern testen.
 Bis die Treibersoftware einwandfrei funktioniert, gibt es einen Workaround von mir, der wirklich zufällig gefunden wurde: Die Feitian PKI Card lässt PINs mit Zahlen mit mindestens 4 und maximal 16 Stellen zu, dabei ist die PUK (zum entsperren und neu setzen der PIN) grundsätzlich nur über den Rechner einzugeben und damit keiner weiteren Einschränkung unterworfen. Die PIN sollte 4-, 6-, maximal 8-stellig sein, da der Gemalto Leser keine längeren PINs verarbeitet (Einschränkung in der Firmware des Lesers), wenn man diesen Leser mit PinPad benutzen will. Karten, deren PIN mit den PinPad Lesern auf eine ungerade PIN-Länge gesetzt und/oder modifiziert wurden, lassen sich ohne Neusetzen der PIN nicht mehr mit dem einfachen Leser ohne Pad benutzen (und umgekehrt).
 
 weiteres update: Openvpn

für die Nutzung von PinPad-Readern muss nur eine Zeile in die conf-Datei eingefügt werden (nach pkcs11-provider): pkcs11-protected-authentication 1 /usr/lib/onepin-opensc-pkcs11.so

dann wird automatisch das PinPad zur Eingabe benutzt, wenn es in der opensc.conf aktiviert ist.

Bei der OpenPGP-Karte ist das Pinpad leider noch nicht nutzbar. 

Bitte sämtliche Fragen an mail@lug-balista stellen, bitte keine html-Mails (Spamfilter aktiv).

(rw)

Eine der einfachen Möglichkeiten wird über das 'encfs' Filesystem (im Userspace) realisiert. Damit werden Ordner erstellt, die die verschlüsselten Daten enthalten und softwaremäßig auf einen anderen Ordner abgebildet werden, der die Dateien im Klartext enthält (temporär, solange gemountet!). Der Vorteil liegt darin, dass der Ursprungsordner mit den verschlüsselten Dateien zusätzlich auch nichtverschlüsselte Dateien enthalten kann. So kann zwischen wichtigen Dateien (verschlüsselt) und anderen unterschieden werden , ohne verschiedene Ordner (Datenträger) verwenden zu müssen.

Die vollständigen Kommandos (Konsolenbedienung!) und Erläuterungen können in den Hilfeseiten (manpages (man encfs/encfsctl)) nachgeschlagen werden.

Die einzigen Einschränkungen, die ich bei der Anwendung feststellte, sind, dass der entgültige, errechnete Schlüssel eine Textdatei sein muss, die mittendrin keine Zeilenvorschübe (ASCII 10) enthält und maximal 2 kB groß sein darf (bei Anwendung des Parameters -S), bei Nutzung der Option --extpass=... gibt es m.W. keine Beschränkungen.

Um nicht jedesmal auf die Konsole gehen zu müssen, habe ich für Medien wie USB-Sticks, USB-Festplatten und SD-Cards passende Scripte entwickelt, die sogar nach erstmaliger Einrichtung des Datenträgers auf der Kommandozeile dann einen vollautomatischen Betrieb ohne Passworteingabe ermöglichen.

Nötig ist dazu die richtige Kombination von Dateien auf dem entfernbaren Datenträger und den dazu passenden Scripten und Dateien auf dem Rechner, der den verschlüsselten Datenträger automatisch mounten soll. Damit wird auch die Frage nach der Sicherheit der verschlüsselten Daten beantwortet. Solange nicht beide Komponenten zusammen in unbefugte Hände gelangen, ist der Zugriff auf die Daten praktisch nicht möglich. Es wird zwar der Key zur Entschlüsselung mit auf dem Datenträger gespeichert, er ist jedoch nicht von den übrigen verschlüsselten Daten zu unterscheiden, und es fehlen natürlich auch die Angaben, wie dieser Key überhaupt zur Entschlüsselung eingesetzt werden kann (z.B. durch Anwendung von Umwandlungsprozessen und Rechenvorschriften).

Das hier vorgestellte Verfahren eignet sich auch für Datenträger, die bereits Daten enthalten, da nach meinen Erfahrungen  wohl niemand bereits solche kryptischen Dateinamen, wie sie hier verwendet werden, auf seinem Datenträger hat. Trotzdem erfolgt die Anwendung meiner Scripte auf eigene Gefahr, jegliche Haftung ist ausgeschlossen.

Vorbereitungen:

Es wird eine root-Konsole benötigt, die während der Ersteinrichtung geöffnet bleibt.

Zunächst muss der vorgesehene Datenträger immer eindeutig durch das Betriebssystem erkannt werden können und auch immmer an einer eindeutigen Stelle gemountet werden.
Den besten Mechanismus bieten inzwischen die udev-Regeln, da sie unabhängig von der gewählten Desktopoberfläche funktionieren.

Beim Anschließen des Datenträgers zeigt die Beobachtung der syslog-Datei

tail -f /var/log/syslog

(Anzeige beenden mit Strg(Ctrl)+C), welche Gerätedatei (/dev/xxx) neu dafür angelegt wird.

Die Ausgabe des Befehls

udevadm info --attribute-walk --name=/dev/xxx

gibt Informationen aus, die für die Erstellung einer eigenen udev-Regel benötigt werden. Gesucht sind eindeutige Merkmale, wie Seriennummern und Gerätearten. Aufgepasst, es dürfen nur Attribute (Zuordnungen) aus dem Hauptblock (1.angezeigter Block) und einem! anderen Block gemeinsam in einer Regel verwendet werden, damit die Regel auch ausgewertet wird.

Hier mal ein Beispiel:

Die syslog-Ausgabe beim Einstecken eines USB-Sticks:

Mar 26 09:12:16 (Rechnername) kernel: [32495.736077] usb 5-1: new high speed USB device using ehci_hcd and address 3
Mar 26 09:12:16 (Rechnername) kernel: [32495.870110] usb 5-1: configuration #1 chosen from 1 choice
Mar 26 09:12:16 (Rechnername) kernel: [32495.870436] scsi1 : SCSI emulation for USB Mass Storage devices
Mar 26 09:12:16 (Rechnername) kernel: [32495.870776] usb 5-1: New USB device found, idVendor=0930, idProduct=6545
Mar 26 09:12:16 (Rechnername) kernel: [32495.870783] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 26 09:12:16 (Rechnername) kernel: [32495.870789] usb 5-1: Product: DataTraveler 2.0
Mar 26 09:12:16 (Rechnername) kernel: [32495.870793] usb 5-1: Manufacturer: Kingston
Mar 26 09:12:16 (Rechnername) kernel: [32495.870798] usb 5-1: SerialNumber: 0014785FE5905B8A0F0A018C
Mar 26 09:12:16 (Rechnername) kernel: [32495.870831] usb-storage: device found at 3
Mar 26 09:12:16 (Rechnername) kernel: [32495.870835] usb-storage: waiting for device to settle before scanning
Mar 26 09:12:16 (Rechnername) NetworkManager: <debug> [1238055136.339192] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_930_6545_0014785FE5905B8A0F0A018C').
Mar 26 09:12:16 (Rechnername) NetworkManager: <debug> [1238055136.442704] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_930_6545_0014785FE5905B8A0F0A018C_if0').
Mar 26 09:12:16 (Rechnername) NetworkManager: <debug> [1238055136.472103] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_930_6545_0014785FE5905B8A0F0A018C_usbraw').
Mar 26 09:12:18 (Rechnername) chipcardd[3236]: devicemanager.c: 3373: Changes in hardware list
Mar 26 09:12:21 (Rechnername) kernel: [32500.868257] usb-storage: device scan complete
Mar 26 09:12:21 (Rechnername) kernel: [32500.869072] scsi 1:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS
Mar 26 09:12:21 (Rechnername) NetworkManager: <debug> [1238055141.383785] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_930_6545_0014785FE5905B8A0F0A018C_if0_scsi_host').
Mar 26 09:12:21 (Rechnername) NetworkManager: <debug> [1238055141.388714] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/usb_device_930_6545_0014785FE5905B8A0F0A018C_if0_scsi_host_scsi_device_lun0').
Mar 26 09:12:23 (Rechnername) kernel: [32503.297957] sd 1:0:0:0: [sda] 7936000 512-byte hardware sectors (4063 MB)
Mar 26 09:12:23 (Rechnername) kernel: [32503.298243] sd 1:0:0:0: [sda] Write Protect is off
Mar 26 09:12:23 (Rechnername) kernel: [32503.298243] sd 1:0:0:0: [sda] Mode Sense: 23 00 00 00
Mar 26 09:12:23 (Rechnername) kernel: [32503.298243] sd 1:0:0:0: [sda] Assuming drive cache: write through
Mar 26 09:12:23 (Rechnername) kernel: [32503.302390] sd 1:0:0:0: [sda] 7936000 512-byte hardware sectors (4063 MB)
Mar 26 09:12:23 (Rechnername) kernel: [32503.302979] sd 1:0:0:0: [sda] Write Protect is off
Mar 26 09:12:23 (Rechnername) kernel: [32503.302988] sd 1:0:0:0: [sda] Mode Sense: 23 00 00 00
Mar 26 09:12:23 (Rechnername) kernel: [32503.302993] sd 1:0:0:0: [sda] Assuming drive cache: write through
Mar 26 09:12:23 (Rechnername) kernel: [32503.302999] sda: sda1
Mar 26 09:12:23 (Rechnername) kernel: [32503.351113] sd 1:0:0:0: [sda] Attached SCSI removable disk
Mar 26 09:12:24 (Rechnername) NetworkManager: <debug> [1238055144.405598] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/storage_serial_Kingston_DataTraveler_2_0_0014785FE5905B8A0F0A018C_0_0').
Mar 26 09:12:24 (Rechnername) NetworkManager: <debug> [1238055144.682780] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/volume_uuid_CCF2_1D04').
Mar 26 09:12:24 (Rechnername) kernel: [32504.382131] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Mar 26 09:12:24 (Rechnername) hald: mounted /dev/sda1 on behalf of uid 1000

Die Ausgabe von udevinfo:

(Rechnername)# udevadm info --attribute-walk --name=/dev/sda

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/block/sda':
KERNEL=="sda"
SUBSYSTEM=="block"
DRIVER==""
ATTR{range}=="16"
ATTR{removable}=="1"
ATTR{size}=="7936000"
ATTR{capability}=="13"
ATTR{stat}==" 135 7729 8690 1080 1 0 1 212 0 1088 1292"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb5/5-1/5-1:1.0/host1/target1:0:0/1:0:0:0':
KERNELS=="1:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{device_blocked}=="0"
ATTRS{type}=="0"
ATTRS{scsi_level}=="0"
ATTRS{vendor}=="Kingston"
ATTRS{model}=="DataTraveler 2.0"
ATTRS{rev}=="PMAP"
ATTRS{state}=="running"
ATTRS{timeout}=="30"
ATTRS{iocounterbits}=="32"
ATTRS{iorequest_cnt}=="0x10a"
ATTRS{iodone_cnt}=="0x10a"
ATTRS{ioerr_cnt}=="0x2"
ATTRS{modalias}=="scsi:t-0x00"
ATTRS{evt_media_change}=="0"
ATTRS{queue_depth}=="1"
ATTRS{queue_type}=="none"
ATTRS{max_sectors}=="240"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb5/5-1/5-1:1.0/host1/target1:0:0':
KERNELS=="target1:0:0"
SUBSYSTEMS==""
DRIVERS==""

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb5/5-1/5-1:1.0/host1':
KERNELS=="host1"
SUBSYSTEMS==""
DRIVERS==""

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb5/5-1/5-1:1.0':
KERNELS=="5-1:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="usb-storage"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bNumEndpoints}=="02"
ATTRS{bInterfaceClass}=="08"
ATTRS{bInterfaceSubClass}=="06"
ATTRS{bInterfaceProtocol}=="50"
ATTRS{modalias}=="usb:v0930p6545d0100dc00dsc00dp00ic08isc06ip50"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb5/5-1':
KERNELS=="5-1"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="80"
ATTRS{bMaxPower}=="200mA"
ATTRS{urbnum}=="988"
ATTRS{idVendor}=="0930"
ATTRS{idProduct}=="6545"
ATTRS{bcdDevice}=="0100"
ATTRS{bDeviceClass}=="00"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="5"
ATTRS{devnum}=="3"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="0"
ATTRS{quirks}=="0x0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Kingston"
ATTRS{product}=="DataTraveler 2.0"
ATTRS{serial}=="0014785FE5905B8A0F0A018C"

looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb5':
KERNELS=="usb5"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
ATTRS{configuration}==""
ATTRS{bNumInterfaces}==" 1"
ATTRS{bConfigurationValue}=="1"
ATTRS{bmAttributes}=="e0"
ATTRS{bMaxPower}==" 0mA"
ATTRS{urbnum}=="213"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
ATTRS{bcdDevice}=="0206"
ATTRS{bDeviceClass}=="09"
ATTRS{bDeviceSubClass}=="00"
ATTRS{bDeviceProtocol}=="00"
ATTRS{bNumConfigurations}=="1"
ATTRS{bMaxPacketSize0}=="64"
ATTRS{speed}=="480"
ATTRS{busnum}=="5"
ATTRS{devnum}=="1"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="8"
ATTRS{quirks}=="0x0"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="Linux 2.6.26-1-486 ehci_hcd"
ATTRS{product}=="EHCI Host Controller"
ATTRS{serial}=="0000:00:1d.7"
ATTRS{authorized_default}=="1"

looking at parent device '/devices/pci0000:00/0000:00:1d.7':
KERNELS=="0000:00:1d.7"
SUBSYSTEMS=="pci"
DRIVERS=="ehci_hcd"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x265c"
ATTRS{subsystem_vendor}=="0x144d"
ATTRS{subsystem_device}=="0xb035"
ATTRS{class}=="0x0c0320"
ATTRS{irq}=="23"
ATTRS{local_cpus}=="1"
ATTRS{local_cpulist}=="0"
ATTRS{modalias}=="pci:v00008086d0000265Csv0000144Dsd0000B035bc0Csc03i20"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

Die daraus erstellte udev-Regel: (als '89-eigene-regeln.rules' in /etc/udev/rules.d/ eingefügt)

ACTION!="add|change", GOTO="eigene_regeln_end"

...
...
SUBSYSTEM=="block", SUBSYSTEMS=="usb", ATTRS{serial}=="0014785FE5905B8A0F0A018C", NAME+="stick1"
SUBSYSTEM=="block", SUBSYSTEMS=="usb", ATTRS{serial}=="0014785FE5905B8A0F0A018C", RUN+="/usr/local/sbin/automount 5 nutzer 1 (dateisystem)"
...
...

LABEL="eigene_regeln_end"

Jede Regel steht in einer einzigen Zeile ohne Umbruch!

Zuerst wird dem Stick ein eindeutiger Gerätename zugeordnet, dann erfolgt ein Aufruf eines selbst zu erstellenden Scripts mit den benötigten Funktionen. Damit mehrere Geräte gleichzeitig , auch mit verschiedenen Passwortdateien, zu betreiben sind, wird es mit mindestens drei Parametern aufgerufen ( Nr.= lfd.Nr.Passwortdatei, nutzer= euer Nutzername, dann eine eindeutige Nummer und evtl. noch das Dateisystem ( z.B. ext2)). Die letzte Angabe wird benötigt, falls es eine Falscherkennung durch den Mountbefehl pmount gibt. Das Script läuft im Hintergrund, daher darf es keine Interaktivitäten geben. Ich habe mein Script 'automount' genannt und in dem Ordner /usr/local/sbin abgelegt. Die Zugriffsrechte des Scripts werden nach der Erstellung so restriktiv wie möglich gesetzt. Da die udev-Regeln als root ausgeführt werden, braucht es nur die root Ausführungsrechte zum Lesen und Ausführen.

Das 'automount'-Skript: abgelegt in /usr/local/sbin/automount (Die Zugriffsrechte werden nach der Erstellung auf r-x------ gesetzt (500), owner root:root)

#!/bin/sh

##############################
#
# Script zum automatischen Mounten von encfs-verschlüsselten Dateisystemen auf
# entfernbaren Datenträgern, Verzeichnisse werden bei Bedarf erstellt
# (und mit einem weiteren Script wieder entfernt)
#
# Version 0.5 Rolf Wald, LUG Balista Hamburg e.V., 2009
#
# License: GPL (Debian Version)
#
# Aufruf mit den Parametern: "lfd.Nummer des Schlüsselscripts" "Name des
# angemeldeten Benutzers" "eindeutige Nr. des Geräts lt. udev-Regel"
# (optional: "Name des Dateisystems (wie nach mount -t anzugeben)")

# Bei gesonderter Behandlung von SD-Card Lesern muss die 'sudoers'-Datei angepasst
# werden (mit visudo):(sdcard) - Eintrag wie in fstab
# nutzer ALL=NOPASSWD: /bin/ls -s /media/(sdcard) /media/stick*
#
#
##############################
# Nummer der externen Passwortabfrage
PASSNUMMER=$1

# angemeldeten Nutzer übergeben
CRYPTUSER=$2

# Nummer als Parameter übergeben
MEDIUM=$3

# wenn weiterer Parameter vorhanden, dann in Variable übernehmen
# z.B. Sonderbehandlung von ext2 formatierten Devices
# (werden nicht korrekt von pmount erkannt)
if [ $# -le 3 ]
    then
        DATSYS="auto"
    else
        DATSYS=$4
fi

# Mounten mit den Rechten des angemeldeten Nutzers
# (sonst keine Schreibrechte!)
if [ "$DATSYS" == "auto" ]
            then
                sudo -u $CRYPTUSER pmount /dev/stick$MEDIUM
            else
                sudo -u $CRYPTUSER pmount -t $DATSYS /dev/stick$MEDIUM
        fi

# Ereignis in der syslog-Datei anzeigen
logger "cryptstick vorhanden!"

# Wenn das Script mehrmals aufgerufen wird, Device erst korrekt unmounten
# sonst ist der Moutpoint nicht frei
if [ "cat /etc/mtab | grep /home/$CRYPTUSER/stick$MEDIUM | wc -l" -gt 0 ]
    then
        fusermount -u /home/$CRYPTUSER/stick$MEDIUM

        # Mounten mit den Rechten des angemeldeten Nutzers
        #  (sonst keine Schreibrechte!)
        if [ $DATSYS == "auto" ]
            then
                sudo -u $CRYPTUSER pmount /dev/stick$MEDIUM
            else
                sudo -u $CRYPTUSER pmount -t $DATSYS /dev/stick$MEDIUM
        fi
fi

# Sonderbehandlung eines eingebauten SD-Card Lesers
# Wenn dafür bereits ein Eintrag in der 'fstab' vorhanden
# ist, wird pmount mit den Angaben in der 'fstab' (hier /media/sdcard)
# ausgeführt.
if [ ! -d /media/stick$MEDIUM ]
        then
                if [[ -b /dev/mmcblk0 ]]
                        then
                                ln -s /media/sdcard /media/stick$MEDIUM
                                logger link!!!
                fi
fi

sleep 1

# Ordner vorhanden ?, sonst erstellen!
if [ ! -d /home/$CRYPTUSER/stick$MEDIUM ]
    then
        sudo -u $CRYPTUSER mkdir /home/$CRYPTUSER/stick$MEDIUM
fi

# Einhängen des encfs Filesystems
export MEDIUM
sudo -u $CRYPTUSER encfs --extpass="/usr/local/sbin/crymount$PASSNUMMER $MEDIUM" \
/media/stick$MEDIUM /home/$CRYPTUSER/stick$MEDIUM

ERFOLG=$?
logger $ERFOLG

Nach der Eingabe von udevadm control --reload_rules werden die neuen Regeln eingelesen.

Zunächt muss der Stick einmal ordnungsgemäß entfernt werden (unmount mit den üblichen Methoden des Desktops), damit der Stick aus- und wieder eingesteckt werden kann.

Nach dem Wiedereinstecken läuft jetzt das automount-Script mit den in der udev-Regel eingestellten Parametern ab. Danach wird in der root-Konsole der Befehl /usr/local/sbin/automount 5 nutzer 1 aufgerufen. Es gibt nun verschiedene mögliche Szenarien, abhängig von den Dateien, die bereits auf dem Stick vorhanden waren (im Hauptverzeichnis: hier /media/stick1). (Die Fehlermeldungen beim 'Mounten' können ignoriert werden) :

1. Der Stick enthielt keine ".encfs6.xml" Datei und auch keine Passwortdatei "xyz", dann wurde eine ".encfs6.xml" Datei erstellt, die ohne Passworteingabe funktioniert (Fehlermeldung SSL-Cipher...). Die ".encfs6.xml" muss jetzt wieder gelöscht werden.

2. Es ist die richtige Passwortdatei vorhanden, die ".encfs6.xml" ist nicht vorhanden oder gehört zu einer anderen Passwortdatei. Jetzt wird 'das Passwort ist falsch' angezeigt. Auch hier ist die ".encfs6.xml" zu löschen.

3. Es sind die zueinander passenden Dateien ".encfs6.xml" und"xyz" vorhanden. Es erfolgt keine Fehlermeldung bei der Entschlüsselung. Hier muss nichts mehr getan werden. Wir sind mit der Einrichtung fertig.

Falls noch keine Passwortdatei "xyz" vorhanden ist, muss sie jetzt angelegt werden.

Anlegen der Passwortdatei und des passenden Scripts

Die Schlüsseldatei wird auf dem Stick erzeugt:

dd if=/dev/urandom of=/media/stick1/Kjzsbd5vS3-z=gWl bs=1 count=2578

Die Datei darf beliebig groß sein und sollte auch einen kryptischen Namen bekommen, nach durchlaufen der Rechenschritte zur endgültig verwendeten Datei sollte diese max. 2 KB groß sein, die Dokumentation zu encfs hat da eine Grenze aufgezeigt (gilt nur bei -S, Passworteingabe aus Standardeingabe lesen!).

Und jetzt kommt eure Phantasie ins Spiel, denkt euch eine Kette von Bearbeitungen der Schlüsseldatei aus. die die wirklich zu verwendende Datei erzeugt.Beispiel:
Verwendet werden können alle Befehle, die in einer Pipe arbeiten, d.h. sowohl von Standardeingabe lesen als auch auf Standardausgabe schreiben können: dd, base64, caesar, openssl.

Für diese "sensible" Information wird jetzt eine eigene, später nur für den Nutzer ausführbare, Datei erstellt, ich nenne sie crymount5 (Nummer wie bei udev-Regel angegeben und Name wie im automount Script)

:Das 'crymount'-Skript: abgelegt in /usr/local/sbin/crymount5 (Die Zugriffsrechte werden nach der Erstellung auf r-x------ gesetzt (500), owner nutzer:nutzer)

#!/bin/sh

##############################
#
# Script zur Errechnung des zu verwendenden Schlüssels aus einer Passwortdatei
#
# Version 0.2 Rolf Wald, LUG Balista Hamburg e.V., 2009
#
# License: GPL (Debian Version)
#
# Aufruf mit dem Parameter "vergebene lfd. Nummer des verschlüsselten
# Datenträgers"
#
##############################


MEDIUM=$1
logger crypt$MEDIUM

dd if=/media/stick$MEDIUM/Kjzsbd5vS3-z=gWl bs=1 skip=33 count=1047 | \

openssl enc -rc4-40 -k 0a0b0c0d0e -nosalt | base64 | dd bs=1 skip=11 count=999 | \

base64 | tr -d '\n'

Bitte beachten: Die Passworteingabe über die Standardeingabe bei encfs funktioniert m.E. nur mit druckbaren Zeichen (daher base64 kodieren) und wird mit ASCII Zeichen 10 abgeschlossen (der Befehl tr -d '\n' filtert daher diese aus, damit das Passwort nicht abgeschnitten wird), besser ist die Nutzung des Parameters '--extpass=...', dort konnte ich keine Beschränkungen feststellen.

Im Falle der o.a. Punkte 1 und 2 wird (nach Löschen der ".encfs6.xml") noch einmal der Befehl

/usr/local/sbin/automount 5 nutzer 1 in der root-Konsole aufgerufen.

Bei der Ersteinrichtung erfolgt hier dann die Frage nach der Verschlüsselungsart, z.B. p (paranoia-mode, weitere Angaben siehe man encfs), dann holt sich das Script automatisch das Passwort mit Hilfe von crymount5.

Wenn alles ohne Fehlermeldung geklappt hat, überprüfen wir die Einrichtung des crypt-Dateisystems.

Es müssen die Ordner /media/stick(nr)  (nr=1...(wie in der udev-Regel angegeben)), sowie /home/nutzer/stick(nr) vorhanden sein. Nun ist zum Test mal eine Datei im Ordner /home/nutzer/stick(nr) zu speichern. Es erscheint dann ein verschlüsselter Dateieintrag im Ordner /media/stick(nr)

Damit ist die Ersteinrichtung abgeschlossen, den Stick bitte noch nicht entfernen, er ist noch im Dateisystem eingehängt. Entweder erst die u.a. Dateien erstellen und cryumount.sh aufrufen oder

fusermount -u /home/nutzer/stick(nr) && pumount /dev/stick(nr)

Damit das Unmounten genauso komfortabel geschieht, gibt es auch dafür ein Script.
Am Besten legt man sich ein Programmsymbol auf seinem Desktop an, welches das Script ausführt. Ich habe es unter /usr/local/bin/cryumount.sh abgespeichert. (Es kann sowohl als Nutzer als auch als root genutzt werden.). Aufruf cryumount (nutzer) (zahl)  (= Max Zahl an Geräten (wie in udev-Regel eingesetzt))

Beispiel: cryumount.sh peter 5 (Der Nutzer peter hat 5 Geräte in seiner udev-Regel)

#!/bin/sh

##############################
#
# Script zum sicheren Entfernen gemounteter Datenträger mit encfs Verschlüsselung
#
# Version 0.5 Rolf Wald, LUG Balista Hamburg e.V., 2009
#
# License: GPL (Debian Version)
#
# Aufruf mit den Parametern "angemeldeter Benutzer" und "max. Zahl der Geräte"
#
# Erfordert Nutzereinträge in 'sudoers' (mit visudo)
# nutzer ALL=NOPASSWD: /bin/umount -l /dev/*, /bin/rm -f /media/stick*,
#  /bin/rmdir /media/stick*
#
##############################

CRYPTUSER=$1
ZAHL=$2

for (( I=1 ; $I<=$ZAHL ; I++ ))
   do

      # Unmounten des encfs-Dateisystems und entfernen des Verzeichnisses
      fusermount -u /home/$CRYPTUSER/stick$I ; rmdir /home/$CRYPTUSER/stick$I

      # Unmounten des Datenträgers (in Fehlerfall (bereits entfernter Datenträger!)
      # wird unmounten erzwungen und das Verzeichnis gelöscht
      ERGEBNIS="pumount /media/stick$I 2>&1 | grep Fehler | cut -f 3 -d " ""
     if [ $ERGEBNIS != "" ] ; then
         sudo /bin/umount -l /media/stick$I && sudo /bin/rm -f /media/stick$I/.*
         sudo /bin/rmdir /media/stick$I
     fi

# falls das Verzeichnis ein Symlink ist, entfernen! (wird bei Datenträgern,
# die in der fstab verzeichnet sind, benötigt)
      if [[ -h /media/crypt$I ]] ; then sudo /bin/rm -f /media/crypt$I ; fi
   done

... und es steht ab sofort der beschriebene Automatismus zur Verfügung.

Anmerkungen:  Die hier beschriebene Vorgehensweise solltet ihr natürlich mit euren eigenen, angepassten Eingaben vornehmen, z.B. nutzer ersetzen durch euren angemeldeten Namen. Die Errechnung des Schlüssels ist mit der Veröffentlichung hier auch abzuändern (andere Zahlenwerte, Algorithmen o.ä.), ansonsten funktioniert sogar copy und paste der fettgedruckten Kommandos.

(rw)