Fwd: continued discussion on trustworthiness of gnome-screensaver

["William Jon McCann" <mccann jhu edu>]

---------- Forwarded message ----------
From: Ray Strode <halfline gmail com>
Date: Feb 23, 2007 6:52 PM
Subject: Re: continued discussion on trustworthiness of gnome-screensaver
To: Mahmood Ali - Sun Microsystems <Mahmood Ali sun com>
Cc: William Jon McCann <mccann jhu edu>


I forgot to paste the message I mentioned I would in my previous mail.

Inline below:
-------------

Hi,
> José has started working on Thinkfinger[1] support, and already has a
> few patches ready[2]. There's a PAM module, and a library.
>
> This would add support for IBM, Dell and Toshiba laptops, and probably
> most new Sony laptops[3].
Very Cool!
> Do we have any opened bugs about supporting those devices in the
> desktop? (gdm and gnome-screensaver are the only places I can think).
There was an upstream GNOME bug for gnome-screensaver to do some sort
of fingerprint authentication:
http://bugzilla.gnome.org/show_bug.cgi?id=338635

There aren't any Red Hat specific plans currently, mind you.
> How do you think this should be integrated into our desktop? (pretty
> much in the same way you implemented coolkey support, that was you
> right?)
Yea that was me, Bob Relyea, Tomas Mraz, and Nalin Dahyabhai
> I don't think it's possible to have a graphical representation of the
> fingerprint (which is a shame), but I'd be ready to add support to
> anaconda/about-me to create the fingerprints.
>
> Ray, what do you reckon?
Well I have a few comments.   From a user interface perspective what
we probably want is:

1) GDM screen says something like "Please enter username or scan
fingerprint" below the
login entry box, and next it, it would say "Username: ".  A user could
then type their username
or swipe their finger to login.  We probably don't want users to have
to enter their username before
swiping their finger at GDM (although that's probably okay for console login).

2) When the screen is locked, we already know the username, so we
should instead say:
"Please enter password or scan fingerprint".

Now from an implementation point of view, we want
authentication/authorization to happen through PAM.
One place where PAM falls down, though, is event notification. It
can't tell you, e.g., when a person puts a smart card in, or swipes
their finger across the fingerprint scanner, so that needs to be
handled outside of PAM.  The way I would do it is, have a daemon that
sits in the background listening for swipe events.  Anytime someone
swipes their finger it should keep track of who swiped and when.  The
PAM module would then talk to the daemon.  The very first thing it
should do in the sm_authenticate step is check with the daemon to see
if someone has already swiped their finger.  The result of this check
should be a local username (with a valid uid mapped to it) or nothing
if no one swiped recently.  If PAM_USER is set and the swiped username
matches, then we're done and should succeed.  If PAM_USER is set and
the received username that *doesn't* match, then although the person
who swiped is authenticated, they shouldn't be authorized to continue,
so the pam module should fail with an insufficient credentials error
code.   If PAM_USER isn't set then the pam module should accept the
username as authorized, set PAM_USER to that username and succeed.  If
no one recently swiped the their finger, then the daemon isn't going
to return back a username, so we should ask the user for one.  That
means first calling pam_prompt(... TEXT_INFO ... "Please swipe your
finger or enter your username." and then calling pam_get_user() which
will prompt the user for a username and block until they reply.  If
the user enters a username, we're done, this module isn't handling
username/password authentication.  Since pam_get_user sets PAM_USER
already for us,  we just have to return with PAM_IGNORE error code and
let pam_unix (the next module in the pam auth stack) ask for the
password.  Now the tricky part is, how do we handle the situation
where the user swipes their finger while pam_get_user() is blocking?
Note, a pam module should never use threads, because the app that's
loading the pam module might not be using threads.  The answer is we
have to setup some sort of out of band notification.  The daemon is
already running in a separate process.  When it detects the user has
swiped their finger it needs to send out an event that gdm listens
for.  When gdm listens for that event it should just cancel the
current PAM conversation and start a new one.  When that new PAM
conversation starts, pam_sm_authenticate will ask the daemon if anyone
has recently swiped their finger and it will report yes, the pam
module will succeed and the user will get logged in.  Note
notification is a problem *only* for GDM, because the
gnome-screensaver lock dialog is only trying to reauthenticate a user
who is already authorized to use the session.  That means PAM_USER
will always be set before pam_sm_authenticate is called and so the pam
module will never need to call pam_get_user() and block.  Console
login is sort of similiar to gnome-screensaver, because it always asks
for a username first and passes that to pam before initiating the pam
conversation.

Now the question is, how do we notify GDM to cancel its current pam
conversation?  The gdm daemon listens for commands on a fifo in
/var/gdm/.gdmfifo.  If you open the fifo and right
"CANCEL_LOGIN_REQUESTS" to it, then it will cancel all local pam
conversations, so you could have your daemon do that, or you could
have your daemon emit an event that a gdm plugin listened for and
canceled the login requests that way.

Note the plugin architecture isn't there (by there I mean existant)
yet.  There is a bug about, but I can't find it off hand.  It's
blocking on me doing it.

As far as getting the identities into the fingerprint database, I'm
not sure what the best way to go about it is.  Maybe modifying the
firstboot screen? I think that would take some more thought.

--Ray