Nicolas Williams wrote: > 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 > -- > > _______________________________________________ > > Pam-list@redhat.com > https://listman.redhat.com/mailman/listinfo/pam-list
