Re: [gdm-list] Smartcard support in GDM?

[Mike Oliver <Mike Oliver Sun COM>]

gelgey vintela com wrote:
> > Where were you looking for the archives?  Perhaps you found a bad URL
> > that needs to be fixed.
>
> I was looking at http://mail.gnome.org/archives/gdm-list/, which was
> recently displaying the message "No messages have been posted to this
> list yet, so the archives are currently empty". Although now it appears
> to be back up.

It's only showing June 2006 postings.  That's surprising, but
maybe the archive feature is a new addition to the list.  I
have a collection of gdm-list traffic going back much further
than that, I'll see whether it's possible to get those messages
added to the archive.

> > The downside is that PAM has no good way of driving multiple sources
> > of authentication concurrently, so it's painful (at best) to try to
> > do something like "enter your username or insert your smartcard".
>
> The above scenario is what I was trying to solve. I've got a PAM module
> that does PKCS#11 and simply requests a PIN if a token is present, but
> if a token is not present then there must be some way to communicate to
> the user that password-based or token-based authentication is possible,
> and for the PAM module to determine which one was selected.

You could have your module start by invoking the PAM caller's
conversation function with a message that says something like
"please insert your smartcard if you have one, then press 'Enter'
or 'OK' to proceed".  When the conversation function returns
you can then look for a card and if it's there use it, otherwise
return PAM_IGNORE and let the PAM flow fall through to the
following modules.  This means that if the user misses that
opportunity (say, somebody else has already driven the dialogue
past that point and then walked away) then he has to know to
hit 'Restart' to get a fresh opportunity to have his card
recognised.

If you're going to go with this approach then bear in mind what
I said earlier about coexisting with other forms of authentication.
If you had separate PAM modules that were looking to authenticate
on the basis of four different types of smartcard plus two types
of fingerprint reader and three eye scanners and a facial geometry
reader and a voiceprint analyser, and each of those eleven modules
put up their own "do XYZ or hit 'Enter'" prompt then your users
won't be happy.  You'd want only one (customisable) "do XYZ or
ABC or DEF or hit 'Enter'" prompt, presumably issued by a dedicated
PAM module that would always return PAM_IGNORE, and then you'd
want each of the smartcard/whatever modules to quietly do their
thing and fall through if the card/print/eye/voice was not present.

Such a "Do XYZ or ..." prompt module might already exist.  It'd be
nice if there was such a thing as a Big Internet Catalogue Of PAM
Modules.  There might actually be such a thing, I'm sure you can
Google for it as well as I can.

> I'm aware that PAM-enabled applications (such as GDM) should be neutral
> as far as authentication mechanisms are concerned. But I could not see a 
> way of communicating back to PAM that one or another authentication 
> option had been selected, without making GDM at least respond to token 
> insertion events. A kludge to get around the limitations of PAM, as you 
> mentioned.

Right, there's always some sort of kludge required.

> > The simplest way to proceed is to ask the user to "enter your
> > username, or insert your card and then click 'restart' or 'OK'", and
> > define the PAM stack in such a way that it runs your PAM module on
> > 'restart' or 'OK'.  This isn't very slick but it works
>
> Not a very pleasing user experience, but it may be the way to go. I 
> assume that clicking "restart" or "OK" instead of entering a username 
> means that GDM returns a PAM conversation error?

'OK' will probably not cause a conversation error, it will just
return an empty string to the PAM module that invoked the conversation
function.  It's up to the PAM module to decide what to do next.  The
module might loop and keep calling the conversation function until it
gets a non-empty answer or it might return and allow control to pass
to the next module.

I suspect that most modules that ask for a user name will loop forever
until they get one, which is not what you'd want if your smartcard
module's job was to obtain the username from the card and it was
stacked below the ask-the-user-for-his-username module.  You probably
want your module to be configured above the ask-the-user one so that
it can extract the username when a card is presented so the user
doesn't have to enter his name manually.  However, that's just one way
of using a smartcard.  It's arguably more secure to place your module
below the ask-the-user one so that instead of simply grabbing the
username from the card you instead verify that the username provided
by the user matches the username that is tied to the card.  That way
if a blackhat finds a card he can't use it to attack the system until
he finds which user it belongs to.  You could easily write your module
to behave either way, either by depending on a module argument
specified in the PAM configuration or possibly by checking whether a
username has already been supplied at the time your module runs
(although the latter makes assumptions about what might have happened
further up the stack).

It's hard to generalise about what a 'Restart' button might do.  It
might cause the conversation function to return an error, and that might
cause the PAM module that receives that error to do almost anything.
It's also possible that 'Restart' could do something drastic like
causing the process to exit() right there, leaving it up to somebody
else to decide what to do next.  Usually the end result is that PAM
processing gets stopped and then gets started again from the top of
the configured stack, either because some sort of error rippled back
to the application and it was smart enough to run a fresh PAM invocation
within the original process or because the original process died and
a new process was started to take its place.  Either way, this gives
your PAM module a fresh chance to locate and process a smartcard.

BTW, please make sure that your PAM module does the right thing when
it gets invoked outside of the context of an X display (typically :0.0)
running on a system framebuffer.  Too many PAM modules are written to
work only in that context and they misbehave catastrophically in other
contexts, such as on multi-user machines or sometimes even when dealing
with a remote X login.

Mike.
--
mike oliver sun com