Debian Squeeze: Anmeldung mit Gesichtserkennung

Nachdem wir einen entfernten SSH-Login sicher gemacht haben, sollte ja auch der lokale Login an einem Netbook, welches man überall mitnimmt auch vorhanden sein.
Da ich encfs nutze, sind meine Laufwerke verschlüsselt. Sie werden nach einer weiteren Passwortabfrage nach Login entschlüsselt. Also Loginpass !=Encfspass. Warum propagandieren eigentlich so viele Truecrypt wenn der Kernel schon Alles an Board hat?
Somit habe ich mich einmal durch das Internet gesucht und ein Modul für PAM gefunden, welches Gesichtserkennung unterstütz und es ist auch ansprechbar für reine Shellnutzer.
Also habe ich mir die Sourcen von der Downloadseite pam-face-authentication-0.3.tar.gz des Projektes pam-face-authentication heruntergeladen.
Nach dem entpacken des Verzeichnisses der Wahl wurden erst einmal die Abhängigkeiten installiert:

root@sayuri:/home/seraphyn# aptitude install libpam0g-dev cmake python-opencv libx11-6 libx11-dev libqt4-dev libqt4-core libcv-dev libcv2.1 libcvaux-dev libcvaux2.1 libhighgui-dev libhighgui2.1 -y

Und dann ging es an das kompilieren:

root@sayuri:/home/seraphyn/tmp/googlepam/pam-face-authentication-0.3# mkcd build
 root@sayuri:/home/seraphyn/tmp/googlepam/pam-face-authentication-0.3# cmake -D CMAKE_INSTALL_PREFIX=/usr ..
 root@sayuri:/home/seraphyn/tmp/googlepam/pam-face-authentication-0.3# make && make install

Wer möchte, kann natürlich anstelle des make && make install sich auch ein Debianpaket bauen

Als nächstes sollte der Gesichtstrainer benutzt werden, dies geschieht als User mit qt-facetrainer.
Gute Beleuchtung sollte schon sein und man sollte so viele Mitschneiden wie möglich. Es werden in dem Fall verschiedene Sets angelegt. Unter Advanced lässt sich noch die höhe der Sicherheit einstellen. Mehr Auskunft über das Verfahren gibt die Seite LIFEASIKNOW-IT mit dem Artikel PAM Face Authentication Musings: Face Verification using cascaded MACE and LBP based Classifier in welchem auch PDFs zu dem Thema verlinkt sind.

Nachdem diese Hürde geschafft ist bearbeitet man die Datei /etc/pam.d/login und fügt ein auth required pam_face_authentication.so hinzu.
Als Test sollte man erst einemal sufficient nehmen anstelle von required ;)
Wenn Alles wie gewünscht funktioniert braucht man die Fallback-Lösung nicht mehr und kann es mit required scharf stellen.
Wer das ganze noch für ein substitude user (su) haben möchte muss die Datei /etc/pam.d/su im gleichen Stil bearbeiten. Auch hier gilt erst sufficient, dann required. Nicht vergessen als root auch ein qt-facetrainer zu machen, sonst hat die UID keine Sets anhand man das Gesicht erkennen kann.
Wem das ganze mit einem netten „Login timed out after 60 seconds“ quittiert wird, sollte sich mal das File /etc/login.defs anschauen und zwar den Punkt LOGIN_TIMEOUT
Das Ganze geht auch noch für Loginmanager, aber da ich keinen benutze habe ich es hier nicht abgedeckt.

Das Ganze hat aber keinen Sinn, wenn Euer / nicht verschlüsselt ist, denn dann kann man per Grub, Live-Image das ganze aus PAM rausschmeissen.
Meine Empfehlungen für ein Netbook/Laptop im absoluten Paranoiamode sind deshalb:
– Biospasswort
– Grubpassword
– Festplatte/Ordner per encfs/luks verschlüsseln
– OTP setzen für die Loginshell
– Gesichtserkennung für die Loginshell
– USB-Stick/Smartcard mit Zertifikat
– Wenn Dropbox dann gpg
– Der Rest ergibt sich von selbst wie Emailverschlüsselung etc.
Klar ist das vielleicht überspitzt, aber es ist machbar und sind nette Hürden.

Viel Spaß mit der erweiterten Sicherheit

9 Gedanken zu „Debian Squeeze: Anmeldung mit Gesichtserkennung“

  1. >Festplatte per encfs verschlüsseln

    Gibts da Vorteile gegenüber Luks, außer das es transparent arbeitet?

  2. Haben die auch noch eine Bongoversion :)
    Aber es gibt noch eine Software, welches das Tippverhalten misst und dann damit noch authentifiziert.
    Das muss auch noch rein und der Fingerabdruckscanner und …
    Ich glaube am besten ist es keinen Rechner zu nutzen, sondern ein Zengarten, dann ist man beruhigt und kann alles besser nach der Arbeit verwischen.
    Wobei ich, wenn ich es ausrechne, pro kleiner Stein ein Bit, dann brächte ich schon8 Steine für … man kann die Steine dann je nach Größe und Farbe varieren … dann wären Gigabyte, Moment, das geht in die Kosten, ein Steinbruch, ein Radlader … *tipp**rechne* hmmm, die Briefkosten werden mir zu Teuer, denn mein CV wiegt ja dann um die 974632 Tonnen…
    Ich werde mir noch etwas einfallen lassen *g*

  3. Mit encfs kann ich Ordner verschlüsseln, was mir in dem Sinne ein /home bringt, das noch Nutzbar ist, wenn etwas schief ging.
    Luks ist eine feine Sache für swap und komplette Partition. Ich müsste ja bei luks den Ordner im loop mounten.
    Da ich zu 99% encfs nutze ist luks nur die dreingabe für /.
    Das habe ich etwas anderes gehandelt, denn ich kenne keinen Weg in dem Sinne um eine ganze Partition mit encfs zu verschlüsseln wie es luks mit dm kann.

    Wie das lasse ich in meinem Fall mal aus, falls mein netbook doch mal unter meinen Argusaugen verschwindet.
    Ich versuche mit den Beiträgen vor allen zu zeigen, dass einiges geht und es kein Hexenwerk ist. Ich hoffe, dass sich bald mal ein Repository nur für solche Sicherheitsanwendungen auftut, welchen man aber auf Vertrauen kann.
    Ich habe mir schon öfters überlegt mal die kompletten Vor- und Nachteile zu erklären, aber das würde meinen Freizeitrahmen sprengen.
    Zurück zum Thema, warum encfs, weil mir der Rahmen mit fuse von Anfang an gefallen hat und es leicht zu bedienen ist. Ich kann es sehr fein in Scripte einbinden und diese z.B. ausführen lassen um Backups zu machen und danach wieder die Container schliessen, ohne nun ein mount umount auszuführen und der Rechner kann in dem Sinne seine Arbeit weiter im Hintergrund machen, ohne dass ich es bemerke.
    Man hat sich da halt mit der Zeit seine Scriptansammlung gemacht.

    Ist halt ein ich nutze es im Moment. Was sich aber auch mal ändern kann.

    Aber du hast mich auf den Punkt gebracht da nochmal weiterzuforschen. Kann sich ja in dem letzten Jahr was getan haben, außer dem Thema Sicherheitslöcher.

    Grüsse

  4. Zugegebener Weise Nein :)
    Wie schaut es bei Dir aus?
    Ich denke man sollte dort auch mal eine Sicherheits und Performancemessung machen.
    Kennst Du eine Seite, welche dies gemacht hat und glaubwürdig ist in dem Thema?
    Grüsse

  5. Ich habe mich bis dato ehrlich gesagt wenig mit filebasierten Lösungen beschäftigt. Bei FreeBSD ist es seit eh und je Geli, bei Debian Luks, also partionsbasierend.

    Ich bin auch ein wenig zurückhaltend bei Lösungen, die im Userland laufen und bei Fuse insbesondere. Ich hatte mit letzterem früher mal eher schlechte Erfahrungen gemacht.

    Zumindest ein Benchmark unter Ubuntu existiert, dort wird es glaube ich als Default genutzt.

    http://global.phoronix-test-suite.com/?k=profile&u=phorocrypt-16497-10491-19665

  6. Scheint nicht wirklich direkte massive Auswikungen zu haben.
    Wobei der Speicherverbrauch nicht genannt wird.
    Ich mache mich mal in dem Punkt schlau.
    Ich wollte eh demnächst noch auf eine SSD und 2GB bei dem netbook wechseln.
    Falls ich noch eine SSD extra in meinen 1001ha basteln kann ;)
    btw. Norm habe ich die Option geschaltet, dass bekannte User ohne große moderierung posten können, bei vielen funzt das, hast Du keine Mail zur validierung bekommen ?

    Grüsse und geniesse die Sonne :)
    Chris

Kommentare sind geschlossen.