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

PAM and Kerberos



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.

Here's some specific steps we might take to get us there:

 - separate most of the /bin/login.krb5 environment code into a library
   that telnetd/ftpd/etc... can link against;

 - let telnetd/ftpd/etc... use the login.krb5 library calls to avoid
   having to exec() login, but only when the remote client was
   authenticated with suitable credentials other than basic (username/
   password won't do; Kerberos, NTLM, Sun's Diffie-Hellman system will
   do);

 - let telnetd/ftpd/etc... exec /bin/login when the remote client is
   unable to provide suitable authentication credentials and inform
   /bin/login as to wether the connection is secure (encrypted) or not.
   /bin/login should decide wether or not to prompt for a
   username/password and use PAM to authenticate that;

 - add a pam_authorize() call to the PAM API. This call must be rather
   generic and should take typed data as arguments so that the
   individual PAM modules can figure out if they can do anything with
   the arguments;

 - let telnetd/ftpd/etc... call pam_authorize to authorize login access
   to the host, but only following pass-through authentication

 - let /bin/login call pam_authorize to authorize login access to the
   host, after successful authentication;

BTW, it appears that Sun is already doing something along these lines,
though without separating pam_authenticate's authorization function.
Essentially, Sun's PAM_KRB5 has an option, 'acceptor', which causes it's
authenticate() function to return PAM_SUCCESS without any further ado.
This is used in combination with application names specific to
kerberized login services, so that login can skip basic authentication
when called from kerberized services. Or so I guess; the docs[1] are
rather skimpy at this time, and Sun's telnetd/login might be passing
Kerberos ticket/authenticator/tgt to PAM through some additional
enhancements, for all I know.

Nico
--





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