Fingerprint authentication for login, and possibly for sudo

I just started working on this (as this is my personal goal for edgy+1). Will update the information once I have something to present.

AntonyVennard: Hi All, can I recommend the following web site: http://thinkfinger.sourceforge.net/ Certainly for SGS Thompson Fingerprint readers this is a much easier set of sources to work with than the generic bioapi / pam_bioapi.

ChristianNeumair: I'm also currently working on a ThinkFinger GUI. I've also recently forwarded the following proposal to the ThinkFinger author, and the concept would be:
* We add a group "fingerprint" that will have +rw access to USB device nodes for fingerprint sensors
* We allow people to store the fingerprint in ~/.thinkfinger.bir
* This means that you're not required to be root (previously, everything was stored in /etc) and don't need setuid root binaries. It also means that admins can restrict who may access the sensors.
* PAM will consider $HOME/.thinkfinger.bir as fingerprint. I'm not sure whether PAM has access to the $HOME variable but I'm confident
* Notes on the GUI
  * libthinkfinger has its own state machine for authentication. You should use a two-threaded implementation where the worker thread will deal with libthinkfinger interaction, and the GTK+ UI would be in another thread that receives the events. I've got a working CLI sample implementation that uses GQueue and GMutex for this.
  * Probably, it would finally land in gnome-about-me

AntonyVennard: Your solution isn't really nice. I already submitted patches to Timo Hoenig (ThinkFinger author) which inter alia

(a) modify tf-tool to operate on ~/.thinkfinger.bir
(b) modify the PAM module to use getpwnam() and determine the user home directory, equally accessing ~/.thinkfinger.bir

It works quite well, together with

(c) addition of a "fingerprint" group
(d) a udev rule that makes fingerprint reader device nodes +rw for "fingerprint" members

PS: My GTK+ demonstration UI is finished already. It uses multithreading to be able to integrate with the thinkfinger callback mechanism and GTK+ main loop.

AntonyVennard: Taken down my quick and dirty patch - no, it's not the most elegant solution but it does work. Excuse my awful coding, new to the linux api. Another idea for you... can we give the users a choice of where to locate the fingerprints? Home-directories should be default and will be ok for most - I also have a group fingerprint-admin which can add other user's fingerprints (it has write permissions to the relevant directory /etc/thinkfinger/*.bir). Only this group can enroll fps, users themselves cannot unless a member of the fp-admin group enrolls them. A potential option?

Also, do you have the same problem with gksu and if so do you know how to fix it? This would be a major problem for most users as it is not user friendly. Also, are we going to rebuild xscreensaver to allow users to use their fps then?

Antony:
> Another idea for you... can we give the users a choice of where to locate the fingerprints?
I thought about that, and couldn't come up with a use case. Each fingerprint maps directly to a user doesn't it?
Note that I wanted to remove the /etc storage as I think allowing multiple users (a group) to /etc opens the door for cluttering /etc/fingerprint with arbitrary garbage, even with sticky bits set. A fingerprint in my opiniion is clearly user data.

You are proposing to stick with the old strategy of being a super user when acquiring a fingerprint. I think this is fundamentally wrong, since I cannot imagine any admin that has time to be with his users as they acquire their fingerprints, unless the admin is identical with the fingerprint user and can use sudo.

> Only (one) group can enroll fps, users themselves cannot unless a member of the fp-admin group enrolls them. A potential option?
Maybe you could explain what you are trying to achieve with the additional administrative instance involved into fingerprint enrollment?

AntonyVennard: Hi Christian - I am just placing ideas on the table. My extra group allows two things: non-root users to administer fingerprints, add and delete them (including their own) etc. Any user in the fp group may use their fingerprint but not modify it - this ensures a level of security in say a large organisation by allowing management to decide who can and can not authorise fingerprint recording. The same can be achieved by just restricting rights to record fps to root - that way only sudoers can record fps but with less flexibility. As you say, using the sudo root requires an admin there. With an fp-admin group the task can be delegated. It is just an idea, and perhaps it is unnecessary but at least before the package is created the alternatives have been discussed! What do you think? The idea comes from the Windows implementation from Lenovo, which can be configured only to allow certain users enrolment rights although anyone with enrolled fingerprints can use them to authenticate.

ChristianNeumair: Thanks for sharing your ideas Antony! As I previously explained, my idea is to define a set of users that can use the fingerprint reader for enrollment/authentication, via the USB device nodes. I don't see the rationale behind separating fingerprint enrollment and authentications against a stored, user-specific fingerprint. Maybe we can have a third opinion here? SvenHerzberg, what do you think?
> Back in the time I got assigned to this, thinkfinger was nothing more than some hacked-together toys (so you could read and verify your fingerprints with console tools only). There was no such thing as a real mission to get this into an integrated shape for out-of-the-box usage. When I wanted to join the development I was told "just go ahead, create a repo and start hacking", which I did. Later I was told "there is this other guy with a repo, please use his code", when my patches didn't apply anymore because a complete whitespace mess took place. I'm not looking into working on this anymore as I have more pleasant ways to waste my time.

wladston : note that it's important to support login by swiping the finger only. If I have to touch the keyboard to login, the fun behind fingerprint disappears ...
> herzi: also this would break the usecase of fingerprint scanners in tablet pcs (where you want to use the scanner when you have no access to the keyboard)
Andrei Zhekov: Why integrate only thinkpad fingerprint reader? Add support also for libfprint (http://reactivated.net/fprint/wiki/Main_Page )for HP's laptops for example

huayra (2009-04-06):
Fedora 11 is shipping a Fingerprint integration system: http://fedoraproject.org/wiki/Features/Fingerprint
I saw that the full specification in our wiki has not been updated for a while: https://wiki.ubuntu.com/FingerprintAuthentication
Maybe it is time for us to include all the bits and bites that we need to get a fingerprint login supported by GDM?

Javier Jardón (2009-07-18)
Debian: http://wiki.debian.org/FingerForce

Przemyslaw Kulczycki (2009-11-13)
Any news on this spec?

(2010-03-08): Packages for fprintd, sporting full integration into GNOME, are available at https://launchpad.net/~fingerprint/+archive/fprint