[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: PAM and /bin/login, acct_mgmt() vs authenticate()
- From: Nicolas Williams <Nicolas Williams ubsw com>
- To: pam-list redhat com
- Subject: Re: PAM and /bin/login, acct_mgmt() vs authenticate()
- Date: Sat, 19 Aug 2000 10:51:20 -0400
On Sat, Aug 19, 2000 at 04:36:53PM +0400, Michael Ju. Tokarev wrote:
> Nicolas Williams wrote:
> > 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.
Yes, but we're talking only about closing the session and of using
PAM_TTY and PAM_RHOST as the keys to retrieve the necessary state.
Not all PAM apps will have valid PAM_TTY and PAM_RHOST values though;
think of FTP or web services, or of getty. Now, with getty the tty value
will be unique to the localhost so PAM_RHOST can be left unset, but with
FTP you have to make up a unique session id value to stuff into PAM_TTY.
And for web services, well, since the web is stateless you might have a
problem identifying the end of a session anyways. Assuming that you use
short-lived cookies and such things to help keep track of open sessions
you could always just call pam_close_session() for all expired sessions
that haven't been renewed.
> Also some items will that was available to login only (if kerberos
> does not used, then telnetd have no way to see the username).
That's ok. The tty and remote hostname are enough to locate the
necessary state. The "necessary state" here could simply be a utmpx
entry; there you can get at the original PAM_USER and PAM_RUSER items,
set those and let the other modules proceed.
Modules, such as PAM_KRB5, that must do something more than log the end
of the session should be able to retrieve the necessary information.
> 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.
I've proposed just this in the "PAM and Kerberos" thread.
You could have telnetd call pam_start(), then call login() (which would
authenticate the user, if need be, and do all those things /bin/login
does, including fork/exec the users shell), then when the shell exits
telnetd would call logout() to close and end the PAM session.
This way you'd not lose any PAM module state.
But again, go back to the web services example. It may be much harder to
keep all the PAM handles and state in one process so it can do all the
So, I think we have to allow the opening and closing of the same
sessions in different PAM handles and even different processes. This
should be documented and module authors should be warned.
Only modules with open/close session components should be affected.
> 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?
Buffer overflows in telnetd would be bad regardless of wether PAM is
handled completely in telnetd or wether telnetd fork/execs /bin/login.
> 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).
Again, I think PAM modules with open/close session components ought to
be prepared to have to restore state, if there's any, between the call
to pam_sm_open_session() and the call to pam_close_session().
For PAM_KRB5 this may be very hard to do; if the ccache file is named
anything other than /tmp/krb5cc_<uid> then PAM_KRB5's
pam_sm_close_session() will have a hard time figuring out what ccache
filename was used (well, if called from telnetd, and telnetd did
kerberos authentication and setup the ccache, then telnetd will know the
original ccache filename and should be correct as long as neither
PAM_KRB5 nor the user renamed the ccache file).
So PAM_KRB5 might have to keep a database indexed by the appropriate PAM
items (tty/rhost/user/ruser) to remember the name of the ccache files it
creates. Then kinit could have an option for renaming ccache files that
would also update this database; kdestroy should also cooperate to keep
that database upto date.
Regardless we might want to have a liblogin so /bin/login can be
absorbed into telnetd and friends.
[Date Prev][Date Next] [Thread Prev][Thread Next]