[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: PAM and Kerberos



A /bin/login that does not prompt for basic authentication is called
/bin/su.

Part of the problem is that telnetd does some kinds of authentication,
but not basic. That's historical: at first there was only
basic-over-cleartext authentication and it wasn't part of the protocol
standard; when more sophisticated authentication support had to be added
it had to be done at the telnet protocol, where it didn't use to be.

So, ok, have telnetd exec /bin/su when authentication is successfully
done by telnetd and have it call /bin/login (or a BBS, or whatever) when
telnetd does no authentication.

/bin/login and /bin/su should provide options or environment variables
such that telnetd and other callers can pass various bits of useful
information to login/su, such as wether the tty is secure, what kind of
authentication was performed and so on.

Then /bin/login and /bin/su can handle authorization as well as
environmental issues. /bin/login would also perform basic
authentication, as it does now.

PAM (and PAM_KRB5) would only be called by /bin/login and /bin/su.
/bin/login would call pam_authenticate() and /bin/su wouldn't. Both
would call PAM's account/session management functions and PAM_KRB5's
session management would handle renaming/chowning of the user's
credentials file as well as setting KRB5_CCNAME.

If there were to be a pam_authorize() call, again, only /bin/login and
/bin/su would call it; telnetd would just not use PAM.

Nico


On Sat, Aug 12, 2000 at 06:13:46PM -0400, Jeffrey Altman wrote:
> The reason that /bin/login must be replaced is to properly handle the
> credentials cache file.  The credentials cache file is created by
> telnetd as 'root' prior to the knowledge of the actual user account
> that will be used for login.  When the client authenticates with a
> prinicipal but wants to login as an alternate local-account, login is
> the process that knows what the new account name will be.  Therefore,
> only the login process is capable of performed the chown()/chgrp() on
> the user's credential cache file.
> 
> We have a similar problem with the .Xauthority file when X Windows
> System Data Forwarding is implemented.  
> 
> I agree that it would be nice to remove the call to a custom login.
> Perhaps it would be possible to integrate the username/password
> prompting functionality into telnetd so that telnetd knows who the
> real user is.  Then the OS specific /bin/login can be called to handle
> the user environment, profile, shell, ... execution.
> 
> 
> > 
> > With reference to the recent discussion of PAM and Kerberos on the
> > krbdev@mit.deu list (see http://www.mit.edu:8008/menelaus.mit.edu/krb5dev),
> > I'd like to make a few observations:
> > 
> > PAM appears to be used for authorization of login access sometimes, that
> > is, there are modules which perform login authorization checks as part
> > of authentication.
> > 
> > I think this is bad. Authorization should be a separate call in the PAM
> > API, even though each application and module will have different
> > authorization needs and PAM cannot cater to all of them. Any
> > authorization checks that PAM could possibly offer must be fairly
> > coarse, and, really, just gate keepers.
> > 
> > Now, as for Kerberos and kerberized telnet/ftp and replacing /bin/login,
> > here's what I think is the problem:
> > 
> > 1) no state is kept across the telnetd/login exec() boundary,
> > 2) normally login handles [basic] authentication,
> > 3) but with GSS-API/Kerberos it is telnetd that handles authentication,
> >    and login then handles environment issues (becoming the user,
> >    exec()ing the user's shell, ...)
> > 
> > We really ought to have a way of dealing with basic vs. pass-through
> > authentication, everything else remaining the same.
> > 
> > Essentially, we ought to separate handling of pass-through
> > authentication from the kind of authentication that PAM, as it stands
> > now, can provide.
> > 
> > One way to deal with this might be to remove the telnetd/login
> > exec() boundary when pass-through authentication is involved, by
> > absorbing some of login's functionality into telnetd. Already there
> > little or no state to keep when doing basic authentication, since login
> > handles prompting the user for his/her basic credentials.
> 
> 
>                   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
> 
--





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []