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

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

Nicolas Williams wrote:
> On Fri, Aug 18, 2000 at 04:36:34PM -0400, Nicolas Williams wrote:
> > On Fri, Aug 18, 2000 at 04:09:48PM -0400, Nalin Dahyabhai wrote:
> > > You can't pam_end() before the shell starts, because you have to call
> > > pam_setcred(PAM_DELETE_CREDS) and pam_close_session() before you do
> > > that.  For this to work, login forks, handles the last two steps, and
> > > the parent takes care of a proper PAM shutdown when its child exits.
> >
> > Hmmm. Well, that's not how Solaris 2.6 does it.
> >
> > 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().
> In fact, telnetd et. al. on Solaris only set the PAM_TTY and PAM_RHOST
> items before calling pam_close_session().
> > I think this is fine, provided that PAM, or, rather, the various PAM
> > modules can retrieve the necessary state given just those items.
> >
> > So, on Solaris, pam_close_session() is called by telnetd and friends,
> > not by /bin/login.
> I kind of like this ability to use those items to retrieve state and
> close the session later. As long as it works...

This exactly thing was looked for in shadow-utils implementation also,
and that implementation taken the same approach for solaris as solaris's
own login.

This very unclear and at least unreliable to close pam (pam_end)
after opening session and to call pam_start again at the end.
There may be some module's internal state stored as pam_item's that
will be lost then pam_end will be called the first time.
Also some items will that was available to login only (if kerberos
does not used, then telnetd have no way to see the username).
And this is not clear to me how both (login and telnetd) should iteract
with each other in this case, and not having additional login process
as it currently implemented in linux.  Only one (totally different)
approach seemed to be appropriate here -- to avold usage of login
at all (!) -- in case of pam, login is _very_ simple (or at least should
be -- note that I also think that all [uw]tmp[x]/lastlog/etc
also belongs to pam modules, not each application), and can be
just easily in telnetd.  In this case, all things will be in own place
(as I hope -- I may be wrong), and we will have only two processes to
do things clean/right, and there should be no strange flags for login
(i.e. do not do auth) in this case.

There are still some possibilities to have a bugs in telnetd code that
is not good from security point of view (buffer overflows together with
assess to security-sensible data in pam), but this is not _so_ bad since
telnet protocol should have correct implementation already, isn't it?

One another issue with this (not regardless of telnetd+login iteraction,
but about pam_"reopen" between start/end of session -- there _may_ be
a need to have some module have some file(s) opened during the whole
session (this _is_ questionable, but anyway: imagine the chrooted
(that by some reasons have no fork/wait as linux's pamified login),
or (also without fork/exec) that will drop root privileges -- in this
we will lost privileges/ability to reopen say wtmp files to complete
session; this _may_ be achieved by just opening the wtmp file at
pam_open_session and close it in pam_close_session, so we does not need
any additional privileges to close session).  Again -- this _is_
questionable behavour that have some more potential disasters, but who
knows if it will be needed (another approach to achieve the same effect
without that disaster is to fork/wait or to create additional process
inside a pam module for exactly that purpose).


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