On Sun, 20 Aug 2000, Jeffrey Altman <jaltman@columbia.edu> wrote: > > Ok: I requested to login as scott, but lately entered "fred" > > as username and fred's password. > > > > I think that this situation is also possible with kerberized > > telnet, _especially_ when PAM concerned: if administrator rejects > > someone's access to the system (using pam_listfile etc etc), > > 1st login attempt will fail, and after this login will prompt > > for a username. But note that if that second username will be > > not the same as first one, we can have at least strange things > > with kerberos tickets (yes, if second time login will "fallback" > > to plain password auth): Fred on remote machine will have access > > to scott's tickets etc. > > This behavior is by design. It allows the user to authenticate to the > system with their credentials (scott) but login to the account of > another user after proving knowledge of the user's password. > > There is nothing wrong with this. A properly installed telnetd > supporting the telnet AUTH option will be configured to either allow > this behavior or not depending on the administrator's preferences. > There are four levels of acceptable login: Yes, but, I think Michael was writing in the context of /bin/login, PAMified, instead of login.krb5. I think we need to have a liblogin and a /bin/login based on that, that liblogin needs to be PAMified, that telnetd should use liblogin and so on. The crucial issues include: how to communicate to login, and thence PAM, just how the user was authenticated, if at all, with what system and to which principal; we also need to be able to inform login, and PAM, about the security of the TTY. Then we could push handling of valid/user/other/unknown to PAM, where it belongs. [...] > > And the only reliable solution to this is to have login's > > functionality built-in to telnetd, so that it will have full > > control for tickets _and_ usernames. > > I am leaning in this direction for other reasons. I think that is a good thing to do, and if there's a liblogin, then base /bin/login on liblogin. [...] > Until we have a memory based cache for Unix /tmp will have to do. Or a message-based LSA. > > Kerberos tickets are short-lived things (as I know of), so the best > > place for them is a shared memory. And I think that portablilty is > > _not_ a problem here. Most systems have shared memory concept today; > > them are _very_ different from each other -- yes, this _is_ a problem, > > that requires a lot of careful coding. But this problem was already > > solved many times in many packages. > > BTW, storing tickets in shared memory is good for many other places, > > and when only one machine involved (without telnet/etc), isn't it? > > I don't think anyone disagrees with you. It just a question of > finding time to do the work. And right now there is ample evidence > that before significant new code is written the current code base must > be audited with a fine toothed comb. Yes, but, plenty of code exists that could be fashioned into what we've been talking about. We can specify liblogin and its interaction with PAM, we can turn a PAMified login into liblogin, and we can take one of the various PAM_KRB5 modules, touch it up and fit it in. I don't disagree with your audit suggestion. > Jeffrey Altman * Sr.Software Designer > The Kermit Project * Columbia University > 612 West 115th St * New York, NY * 10025 * USA > http://www.kermit-project.org/ * kermit-support@kermit-project.org Nico --
