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 > manipulations > also belongs to pam modules, not each application), and can be > implemented > 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 PAM work. 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 > process > (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 > case > 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. > Regards, > Michael. Nico --
