Discussion:
[Thinkfinger-devel] ThinkFinger, Quo Vadis?
Timo Hoenig
2007-11-15 11:36:59 UTC
Permalink
Hi everyone.

Now, after a break I have been busy catching up with the patches which
have been sent to the list. Thanks everybody who contributed. Also,
many thanks to everyone who stepped in on the list to answer questions
while I was away.

Let me make some comments about the current situation and the future
development.

Currently, ThinkFinger as a library to access the UPEK device is pretty
much finished. There is not much left to fix. Some still encounter the
heating issue where I could not find a proper solution for.

However, all other issues are caused by the hackish implementation of
pam_thinkfinger (because of the uinput hack). I chose to go this route
in order to show that it is possible to use the UPEK device for user
authentication on the Linux desktop.

Reason why this hack exists at all: PAM shortcomings. As we all have
seen that this approach^Whack causes pain, I am about to abandon
pam_thinkfinger completely.

Also, pam_thinkfinger is nothing we want to see in the future as it only
supports one specific fingerprint reader device.

What we want is a unified solution for all fingerprint reader devices.
At best, we'll have a library which supports all kinds of fingerprint
readers. No matter which manufacturer, no matter what model, no matter
whether the device does the fingerprint matching in hardware or whether
software is being used.

Once we have that, we just need to think about how the replacement for
pam_thinkfinger needs to look like. Personally I'd love to develop a
daemon or a volatile process which is being launched using D-Bus system
bus activation. This would decouple the whole unprivileged user space
application / PAM / hardware stack.

It is likely that we will have to fiddle around with other software to
get things going (login managers, screensavers, authentication helpers)
but I am sure it's worth it.

Having that said, I'll release a new version of ThinkFinger. With this
release I'll consider the project to be frozen. Bug fixes will be
accepted, but the project as is will be feature complete.

At that point I will start developing the necessary replacement as
outlined above. Once it is in a usable state I will recommend not to
use pam_thinkfinger as it will then be depreciated.

Please let me know how you think about it or if I have missed anything.

Thanks,

Timo
Daniel Drake
2007-11-15 11:54:08 UTC
Permalink
Hi everyone,
Post by Timo Hoenig
What we want is a unified solution for all fingerprint reader devices.
At best, we'll have a library which supports all kinds of fingerprint
readers. No matter which manufacturer, no matter what model, no matter
whether the device does the fingerprint matching in hardware or whether
software is being used.
I've just released an open source project with these aims (UPEK device
support included amongst 3 other device types).

http://www.reactivated.net/fprint/wiki/

It includes a proof-of-concept PAM module which allows you to login with
your finger, however it doesn't directly offer you the option of typing
your password as an alternative. It also hasn't been tested under
graphical login managers. (it's not quite a pam_thinkfinger replacement)

I've discussed my project with Timo over a couple of emails, and now
that he has the code I hope he considers using my project as a basis for
his efforts. We certainly have the same aims re. decoupling, integration
into existing apps/login managers/screensavers, etc.

If there are any questions about my project/software in general, please
use the fprint mailing list rather than polluting this one. Thanks!

Daniel
Luca Capello
2007-11-15 13:28:33 UTC
Permalink
Hi all!

Cc:ing the FingerForce-devel mailing list because its aim outside Debian
is exactly the same as Daniel and Timo's :-)
Post by Daniel Drake
Post by Timo Hoenig
What we want is a unified solution for all fingerprint reader
devices. At best, we'll have a library which supports all kinds of
fingerprint readers. No matter which manufacturer, no matter what
model, no matter whether the device does the fingerprint matching in
hardware or whether software is being used.
I've just released an open source project with these aims (UPEK device
support included amongst 3 other device types).
http://www.reactivated.net/fprint/wiki/
Thank you for the link.

Are you aware of the Fingerprint Verification System [1]?

Another summary (but far than complete) of the "fingerprint on
GNU/Linux" situation is available at [2].
Post by Daniel Drake
If there are any questions about my project/software in general,
please use the fprint mailing list rather than polluting this
one. Thanks!
I subscribed, since I'm interested in collaborating to bring the
general solution to Debian.

Thx, bye,
Gismo / Luca

Footnotes:
[1] http://fvs.sourceforge.net
[2] http://wiki.debian.org/FingerForce
Luca Capello
2007-11-15 13:12:41 UTC
Permalink
Hi Timo,

nice to see you back on this project :-)

Cc:ing the FingerForce-devel mailing list because this post is
interesting for Debian as well.
Post by Timo Hoenig
Let me make some comments about the current situation and the future
development.
Currently, ThinkFinger as a library to access the UPEK device is pretty
much finished. There is not much left to fix. Some still encounter the
heating issue where I could not find a proper solution for.
FWIW, I use ThinkFinger since the beginning and the latest version with
Christian's and ssh patches is working fine on X60 with Debian sid.
FYI, the Debian Popularity Contest Statistics reports about 80
installation of the ThinkFinger packages I maintain [1] and since their
inclusion in Debian I haven't received any unknown bug.
Post by Timo Hoenig
Having that said, I'll release a new version of ThinkFinger. With this
release I'll consider the project to be frozen. Bug fixes will be
accepted, but the project as is will be feature complete.
While I announced to upload ThinkFinger into unstable (and then testing,
so the next Debian release) [2][3], I haven't prepared it yet because of
the ssh issue Stephen reported on Ubuntu [4]. Have you planned to
include a fix also for this remaining issue?

Thx, bye,
Gismo / Luca

Footnotes:
[1] http://qa.debian.org/popcon.php?package=thinkfinger
[2] http://lists.alioth.debian.org/pipermail/fingerforce-devel/2007-September/000007.html
[3] http://thread.gmane.org/gmane.linux.drivers.thinkfinger/434/focus=467
[4] http://thread.gmane.org/gmane.linux.drivers.thinkfinger/434/focus=479
Timo Hoenig
2007-11-15 14:29:52 UTC
Permalink
Hi Luca!
Post by Luca Capello
nice to see you back on this project :-)
Well, nice to see your constant fidelity in the project :)
Post by Luca Capello
Cc:ing the FingerForce-devel mailing list because this post is
interesting for Debian as well.
I guess it's a good choice to keep the cross postings up until we have
figured out how to proceed properly. That will ensure we'll make the
fingerprint experience on Linux a success.
Post by Luca Capello
FWIW, I use ThinkFinger since the beginning and the latest version with
Christian's and ssh patches is working fine on X60 with Debian sid.
Can you elaborate a little on "working fine". Are you saying that
everything (login, displaymanager, screensaver, authentication helpers
[ such as gksudo, kdesu ]) are working fine?
Post by Luca Capello
FYI, the Debian Popularity Contest Statistics reports about 80
installation of the ThinkFinger packages I maintain [1] and since their
inclusion in Debian I haven't received any unknown bug.
Great!
Post by Luca Capello
While I announced to upload ThinkFinger into unstable (and then testing,
so the next Debian release) [2][3], I haven't prepared it yet because of
the ssh issue Stephen reported on Ubuntu [4]. Have you planned to
include a fix also for this remaining issue?
Thanks for reminding me.

I've committed the following.

Index: pam/pam_thinkfinger.c
===================================================================
--- pam/pam_thinkfinger.c (revision 116)
+++ pam/pam_thinkfinger.c (working copy)
@@ -238,6 +238,7 @@
{
int ret;
int retval = PAM_AUTH_ERR;
+ const char *rhost = NULL;
pam_thinkfinger_s pam_thinkfinger;
struct termios term_attr;
libthinkfinger_init_status init_status;
@@ -252,6 +253,12 @@
if (pam_thinkfinger.isatty == 1)
tcgetattr (STDIN_FILENO, &term_attr);

+ pam_get_item (pamh, PAM_RHOST, (const void **)( const void*) &rhost);
+ if (rhost != NULL && strlen (rhost) > 0) {
+ pam_thinkfinger_log (&pam_thinkfinger, LOG_ERR, "Error: Remote login from host \"%s\" detected.", rhost);
+ goto out;
+ }
+
if ((retval = pam_get_user(pamh, &pam_thinkfinger.user, NULL)) != PAM_SUCCESS)
goto out;
if (pam_thinkfinger_user_sanity_check (&pam_thinkfinger) || pam_thinkfinger_user_bir_check (&pam_thinkfinger) < 0) {


Thanks,

Timo
Luca Capello
2007-11-15 18:02:31 UTC
Permalink
Hi Timo!

Please don't Cc: me, I read the list.
Post by Timo Hoenig
Post by Luca Capello
nice to see you back on this project :-)
Well, nice to see your constant fidelity in the project :)
Even if I don't use the fingerprint reader a lot (most of the time
typing is faster), it's nice to have only it fully supported on
GNU/Linux.
Post by Timo Hoenig
Post by Luca Capello
Cc:ing the FingerForce-devel mailing list because this post is
interesting for Debian as well.
I guess it's a good choice to keep the cross postings up until we have
figured out how to proceed properly. That will ensure we'll make the
fingerprint experience on Linux a success.
Should we keep the fprint mailing list cross posted, too? I cc:ed it,
in case of.
Post by Timo Hoenig
Post by Luca Capello
FWIW, I use ThinkFinger since the beginning and the latest version
with Christian's and ssh patches is working fine on X60 with Debian
sid.
Can you elaborate a little on "working fine". Are you saying that
everything (login, displaymanager, screensaver, authentication helpers
[ such as gksudo, kdesu ]) are working fine?
I'm a bit of an uncommon user, since I don't use any DE at all, so at
least with the tools I use ThinkFinger doesn't cause any problem. These
tools are xdm, vlock, su/sudo and openssh.
Post by Timo Hoenig
Post by Luca Capello
While I announced to upload ThinkFinger into unstable (and then
testing, so the next Debian release) [2][3], I haven't prepared it
yet because of the ssh issue Stephen reported on Ubuntu [4]. Have
you planned to include a fix also for this remaining issue?
Thanks for reminding me.
I've committed the following.
Perfect, it seems you also missed the patch at [1] ;-)

Thx, bye,
Gismo / Luca

Footnotes:
[1] http://thread.gmane.org/gmane.linux.drivers.thinkfinger/420
Timo Hoenig
2007-11-15 19:02:23 UTC
Permalink
Hi!
Post by Luca Capello
Please don't Cc: me, I read the list.
Sorry for that.
Post by Luca Capello
Should we keep the fprint mailing list cross posted, too? I cc:ed it,
in case of.
Well, whenever it makes sense.
Post by Luca Capello
I'm a bit of an uncommon user, since I don't use any DE at all, so at
least with the tools I use ThinkFinger doesn't cause any problem. These
tools are xdm, vlock, su/sudo and openssh.
OK. I just want to collect the what-is-working right now in order to
quickly detect any possible regressions of the upcoming work.
Post by Luca Capello
Perfect, it seems you also missed the patch at [1] ;-)
;-)

Many thanks,

Timo
Stephan Berberig
2007-11-15 18:47:02 UTC
Permalink
Hi Timo,

thanks, it works now.

Best regards,
Stephan
Post by Timo Hoenig
Hi Luca!
Post by Luca Capello
nice to see you back on this project :-)
Well, nice to see your constant fidelity in the project :)
Post by Luca Capello
Cc:ing the FingerForce-devel mailing list because this post is
interesting for Debian as well.
I guess it's a good choice to keep the cross postings up until we have
figured out how to proceed properly. That will ensure we'll make the
fingerprint experience on Linux a success.
Post by Luca Capello
FWIW, I use ThinkFinger since the beginning and the latest version with
Christian's and ssh patches is working fine on X60 with Debian sid.
Can you elaborate a little on "working fine". Are you saying that
everything (login, displaymanager, screensaver, authentication helpers
[ such as gksudo, kdesu ]) are working fine?
Post by Luca Capello
FYI, the Debian Popularity Contest Statistics reports about 80
installation of the ThinkFinger packages I maintain [1] and since their
inclusion in Debian I haven't received any unknown bug.
Great!
Post by Luca Capello
While I announced to upload ThinkFinger into unstable (and then testing,
so the next Debian release) [2][3], I haven't prepared it yet because of
the ssh issue Stephen reported on Ubuntu [4]. Have you planned to
include a fix also for this remaining issue?
Thanks for reminding me.
I've committed the following.
Index: pam/pam_thinkfinger.c
===================================================================
--- pam/pam_thinkfinger.c (revision 116)
+++ pam/pam_thinkfinger.c (working copy)
@@ -238,6 +238,7 @@
{
int ret;
int retval = PAM_AUTH_ERR;
+ const char *rhost = NULL;
pam_thinkfinger_s pam_thinkfinger;
struct termios term_attr;
libthinkfinger_init_status init_status;
@@ -252,6 +253,12 @@
if (pam_thinkfinger.isatty == 1)
tcgetattr (STDIN_FILENO, &term_attr);
+ pam_get_item (pamh, PAM_RHOST, (const void **)( const void*) &rhost);
+ if (rhost != NULL && strlen (rhost) > 0) {
+ pam_thinkfinger_log (&pam_thinkfinger, LOG_ERR, "Error: Remote login from host \"%s\" detected.", rhost);
+ goto out;
+ }
+
if ((retval = pam_get_user(pamh, &pam_thinkfinger.user, NULL)) != PAM_SUCCESS)
goto out;
if (pam_thinkfinger_user_sanity_check (&pam_thinkfinger) || pam_thinkfinger_user_bir_check (&pam_thinkfinger) < 0) {
Thanks,
Timo
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Timo Hoenig
2007-11-15 18:57:59 UTC
Permalink
Hi Stephan,
Post by Stephan Berberig
thanks, it works now.
Alright. Thanks for testing! :)

Timo
Christian Neumair
2007-11-15 20:21:40 UTC
Permalink
Dear Timo,
Post by Timo Hoenig
Once we have that, we just need to think about how the replacement for
pam_thinkfinger needs to look like. Personally I'd love to develop a
daemon or a volatile process which is being launched using D-Bus system
bus activation. This would decouple the whole unprivileged user space
application / PAM / hardware stack.
I thought about that as well. Some ideas:

IMO, we have three use cases:

a) Configuration application wants to verify/update stored fingerprint
b) Authentication (as of now, PAM)
c) Login manager (KDM/GDM) polling for swipes, comparing them with a set
of users' fingerprints (possibly in a particular group) [not yet
implemented in KDM/GDM]

Obviously, we have to allow multiple thinkfinger clients to run at a
time (*), but only one of them should be allowed to access/lock the
reader at a time.


That said, we need a proper locking scheme ensuring that fingerprint raw
data is not "thefted" / "multiplexed" to multiple clients.

I have no experience whatsoever in this area (security-critical hardware
daemons), but I'd like to point out that the current design at least
ensures that the hardware is only "owned" by one client application at a
time (through libusb). How would we ensure that with a daemon?


I'd also like to state that I think it would be possible to implement
this in a secure way with the current design, of course considering its
massive shortcomings.


This is not supposed to be a plea for the old design, just a hint that
we need not only feature parity, but also security parity.


(*) This is required because scenario a) and b) can both be combined:
KDM/GDM may define a particular group of users that will be compared
against auto-swipes, and users may additionally request to be able to
authenticate through PAM, after explicitly specifying their user name.
--
Christian Neumair <***@gnome.org>
Timo Hoenig
2007-11-15 21:23:03 UTC
Permalink
Hi Christian,
Post by Christian Neumair
Post by Timo Hoenig
Once we have that, we just need to think about how the replacement for
pam_thinkfinger needs to look like. Personally I'd love to develop a
daemon or a volatile process which is being launched using D-Bus system
bus activation. This would decouple the whole unprivileged user space
application / PAM / hardware stack.
Thanks for sharing. I really appreciate it.
Post by Christian Neumair
a) Configuration application wants to verify/update stored fingerprint
b) Authentication (as of now, PAM)
c) Login manager (KDM/GDM) polling for swipes, comparing them with a set
of users' fingerprints (possibly in a particular group) [not yet
implemented in KDM/GDM]
Obviously, we have to allow multiple thinkfinger clients to run at a
time (*), but only one of them should be allowed to access/lock the
reader at a time.
That said, we need a proper locking scheme ensuring that fingerprint raw
data is not "thefted" / "multiplexed" to multiple clients.
I have no experience whatsoever in this area (security-critical hardware
daemons), but I'd like to point out that the current design at least
ensures that the hardware is only "owned" by one client application at a
time (through libusb). How would we ensure that with a daemon?
It is even easier when a daemon is the linchpin when it comes down to
actually accessing the device. The daemon could easily claim the USB
devices (note, we only have USB fingerprint readers so far) at start-up.
After that, the daemon can easily implement the locking and control the
access.
Post by Christian Neumair
I'd also like to state that I think it would be possible to implement
this in a secure way with the current design, of course considering its
massive shortcomings.
Indeed. The current limitations caused by both, PAM and user space
applications need to be addressed. We now just have to figure out what
the best solutions looks like. Once this is clear, the implementation
shouldn't be the problem
Post by Christian Neumair
This is not supposed to be a plea for the old design, just a hint that
we need not only feature parity, but also security parity.
You can be sure that security obtains highest priority. Especially as
we have to make people aware of the fact that fingerprint authentication
is _no_ replacement for a password based authentication when using
strong password. At least as long as the fingerprint devices can be
fooled [1] as easy as the available ones. Even though the UPEK device
was a little harder to attack than others, it still was compromised.

Many thanks!

Timo

[1] I have no idea whether the article is online in full length, here's
the press release announcement
German:
<http://www.heise-informationstechnik.de/presseinfo.php/ct,07,05_24_a/41>
Google translated to English:
<http://www.google.com/translate?u=+http%3A%2F%2Fwww.heise-informationstechnik.de%2Fpresseinfo.php%2Fct%2C07%2C05_24_a%2F41&langpair=de|en&hl=en&ie=UTF8>
Loading...