Re: [gdm-list] My questions

["Philippe C. Martin" <pmartin snakecard com>]

Thanks,

It is clearly going to take a fair percentage of my small lot of brain cells 
to corner the issue.

I will start with the daemon and present it to you guys.

Besides the "xdm root gui security flaw" described in the gdm white paper, I 
currently feel (but will probably change my mind) that xdm is more accessible 
(looking at the code) to a newbie for designing such prototype.

So on with the daemon ....

Regards,

Philippe




On Wednesday 05 October 2005 06:43 pm, Bob Doolittle wrote:
> Philippe C. Martin wrote:
> >I do not use Muscle as I have my own framework - I guess my first job is
> > to design a smart card event daemon based on that.
>
> Sounds like a good idea.  And some sort of callback/notification
> mechanism that daemon can support for clients.
>
> >>Yes and no.  PAM gets control when the client (GDM)
> >>calls pam_authenticate().  This should happen when the
> >>client is ready for authentication to occur.  In GDM's case
> >>this is before proceeding to roll out a session for the user.
> >>It could certainly say "please insert your card".  I'm not sure
> >>what you mean by "click to logoff", but that sounds like
> >>something you want to happen within a session, not at
> >>authentication time.  PAM can't get involved after authentication
> >>has completed.  You don't need to authenticate to log off anyway,
> >>so I'm not sure why you'd want this.
> >
> >Under windoze (and I like that feature), once you are logged in through
> > the card, if you remove that card from the reader, the sessions locks.
> > Then your options are
> >1) to insert your card again and authenticate yourself (so from the above,
> > I have a problem with PAM)
> >2) logoff or restart/shutdown the PC
>
> Once you implement your daemon above, there's no reason a
> screen-locker can't subscribe to the event notification and
> invoke a lock action on a card-remove event.  But this has
> nothing to do with PAM or gdm.
>
> >>>As two side questions, and assuming I've understood your meaning:
> >>>
> >>>1) how does PAM handle dialogs ?
> >>
> >>When the client calls pam_start() to initialize the PAM framework,
> >>it passes in a pointer to a "conversation function" that takes a
> >>string for a prompt and returns a string with the response.  The
> >>PAM service modules, when they want to do a user interaction, call
> >>the conversation function in the client.
> >>
> >>>2) where is the responsibility boundary between gdm and PAM
> >>
> >>pam_authenticate() is when the client (gdm) passes control
> >>to PAM.  Depending on what PAM modules you've configured in
> >>pam.conf, and how you've configured them, one or more
> >>modules might get control in succession.  Each does their
> >>notion of "authentication", interacting with the user as
> >>required, and returns PAM_SUCCESS if they are satisfied.  If
> >>all the configured modules return PAM_SUCCESS, then the
> >>pam_authenticate() returns PAM_SUCCESS to the client (gdm).
> >>If any module returns PAM_AUTH_ERR, then that gets returned
> >>to the client.  In the smartcard case, you probably expect
> >>admins to only configure your smartcard PAM module.  Maybe
> >>they'd also like to put a fingerprint scanner PAM module
> >>onto the stack for extra security, as well as a retina-scan
> >>PAM module :-).  It's up to the administrator to use one or
> >>all of these methods by configuring appropriate PAM modules
> >>for GDM (and any other authentication clients like screen lockers)
> >>in pam.conf.
> >
> >I am still confused as to who handles the various dialog boxes: ex I
> > insert a card and the dialog only allows for a PIN while if I click on
> > "By hand", I can choose a user + password the usual way.
>
> Partly my fault - I realized after posting this that my
> description wasn't entirely complete.  Yes, gdm calls
> pam_start() and passes in a pointer to its "conversation
> function" which can take a prompt and return a user
> response.
>
> It then calls pam_authenticate(), and this passes control
> to the PAM framework, which finds the PAM stack for
> gdm and starts invoking the modules on the stack.  Each module
> has a pam_sm_authenticate() entrypoint that gets invoked,
> and when it wants to do a prompt/response interaction
> it looks up the pointer to gdm's conversation function
> passed earlier into pam_start(), and invokes it.  This temporarily
> passes control back to a part of gdm, which displays the
> prompt and a text-input box, and then returns what the
> user typed into the box, returning control back to PAM.
> The service module retrieves the response and does
> whatever authentication magic it desires with it.  It can
> invoke the conversation function as many times as it likes
> to get all the input it needs to authenticate.
> At the end, the service module returns an error, or a
> response indicating the result of the authentication - either
> PAM_SUCCESS or PAM_AUTH_ERR.  Depending on the
> configuration in pam.conf the PAM framework may then invoke
> pam_sm_authentication() in another PAM service module.
> Eventually the PAM framework returns an authentication
> status to gdm.
>
> -Bob

-- 
*************************************
Philippe C. Martin
SnakeCard, LLC
www.snakecard.com
+1 405 694 8098
*************************************