On Mon, Aug 21, 2000 at 01:57:45PM -0400, Jeffrey Altman wrote: > > > 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. > > how does the use of PAM in /bin/login change the security issues? > > > 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. > > how does this belong in PAM? PAM does not support any equivalent > concept. If authentication is being perform by telnetd/sshd/ftpd then > PAM is not involved for authentication. > > Authorization is perform via the krb5_kuserok() function. If the > installer wants PAM to be used for authorization then this function > needs to be modified, not telnetd. Right. krb5_kuserok() belongs in PAM_KRB5. Me thinks. If you can communicate to PAM that the user has been authenticated outside of PAM, and this is the system used to authenticate her and this is the user's principal and THEN call pam_authenticate(), then PAM can check all this, make sure the principal maps to a user, set PAM_USER, if need be, and return PAM_SUCCESS, possibly with no further prompting of the user. Sun seems to be moving in this direction already. XSSO (A PAM-based X/Open standard for single sign-on) seems to have some support for this (see pam_get_mapped_username()). > > > > 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. > > you are assuming that /bin/login can be replaced. I'm not. I'm > working on the assumption that I do not want each and every > application to require its own version of /bin/login. I want the > telnetd/sshd/... packages separated from the Kerberos tree so that > they can be supported independently. Part of the problem with secure > telnet right now is that there are too many versions that have forked > in different directions. I want one package that can support any/all > of the authentication methods as selected by the administrator. > (K4,K5,SRP,TLS,SKIPJACK,...) Yes, but I'm assuming that PAM will take the world by storm and /bin/login will be doing the right thing everywhere. :) Hey, Sun's /bin/login is PAMified, and more or less correctly too. In fact, MIT's telnetd, if modified to call /bin/login with -f <username> when doing valid authentication, should work. Now, it would be nice if /bin/login's interaction with PAM could be specified so all vendors can implement that. > > 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 am not of the belief that PAM should be involved in services that > perform non-interactive (protocol based) logins. PAM can be > configured to require multiple passwords for multiple authentication > modules. This is incompatible with non-interactive authentication as > supported by telnetd/sshd/ftpd/... I'm not trying to push GSS-API into PAM. Rather, I would like there to be a way of communicating external authentication information to PAM so PAM modules, and the system administrator, can make some decisions based on that information. For example, it would be nice to have a way of specifying the security of the current tty so that /bin/su|sudo can later use that information to decide (in PAM) wether to even prompt the user for a password. Yes, this implies a way of restoring PAM state in a later handle (see the PAM list...). > 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 --
