[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM and /bin/login, acct_mgmt() vs authenticate()



On Tue, Aug 22, 2000 at 04:22:43PM -0500, Steve Langasek wrote:
> On Fri, 18 Aug 2000, Nicolas Williams wrote:
> 
> > On Fri, Aug 18, 2000 at 04:09:48PM -0400, Nalin Dahyabhai wrote:
> > > On Fri, Aug 18, 2000 at 03:38:47PM -0400, Nicolas Williams wrote:
> > > > One thing I realize is that several LinuxPAM modules perform account
> > > > authorization checks in pam_sm_authenticate() rather than in
> > > > pam_sm_acct_mgmt(). I think this is a mistake.
> > > 
> > > I think the last time this was brought up on this list, everyone who
> > > voiced an opinion agreed with that.
> 
> > So these modules need fixing then?
> 
> Yes, these modules do need fixing, or at least 'enhancing'.  There's at least
> one scenario where it's been useful to have these modules in the 'auth' stack
> instead of the 'account' stack, namely to prevent administrative passwords
> from being sent in the clear across the network when the login will be
> ultimately rejected.  So being able to interleave authorization and
> authentication functions is sometimes useful, but even so we want to be able
> differentiate between authentication and authorization -- so we should at
> least have the *option* of putting pam_shells, etc. in the 'account' stack.

Agreed. And speaking of preventing the exchange of passwords in
cleartext over the network, it would be nice if there were a way to
indicate to PAM the security of the session/tty (i.e., that it is or is
not encrypted). See my last post on XSSO.

> > There seems to be an assumption that you can call pam_end() without
> > calling pam_close_session() and that later you can call pam_start()
> > again, use pam_set_item to set the relevant items (user, ruser, rhost,
> > tty) and then call pam_close_session() and pam_end().
> 
> I seem to recall this 'assumption' being approved a couple years ago on
> this mailing list; so it's more or less officially considered safe to call
> pam_end() and pam_start() between any two other pam calls without adverse
> effects.  Any state that needs to be saved between calls should be found
> either in the pam items, or in the list returned by pam_getenvlist().
> This also means that pam_close_session() can be called by a different process
> than the one which called pam_open_session() -- *so long as* the first process
> has some way of getting all of the PAM items and PAM environment variables to
> the second process.  

But even that condition is not met in some cases. E.g., Solaris.

> So with telnet, the trick is still making sure that the process calling
> pam_setcred(PAM_DELETE_CREDS) and pam_close_session() has all the info it
> needs to identify the session, whether this be /bin/login after fork()ing, or
> telnetd that's had the relevant information passed to it by some unspecified
> mechanism.

Ok.

Though I think it would be nice if: a) there were a way of specifying
the items that uniquely identify this session (tty/rhost for many apps),
and b) PAM could save and restore state as needed.

Most items (excluding auth tokens), the PAM env variables and the
pam_data needs to be saveable and restoreable. The pam_data cleanup
callback is the perfect place to have modules deal with saving pam_data
combined with a new module method for restoring saved pam_data.

Heck, throw in an enumeration API and such a system would, in fact, be
better than UTMP and UTMPX. Well, if implemented :)

> Steve Langasek
> postmodern programmer


Nico
--





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []