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

Re: PAM and Kerberos

Just some notes about the subject.

I want to remind that usually /bin/login will retry login
attempt in case first one failed.  And this can be very surprizing.
I will give example with plain telnet, not kerberized one:

 machine1$ telnet machine2 -l scott
 Telnet: trying...
 Password: <blah blah blah> (place your favorite invalid password here)
  (some delay usually goes here)
 Login incorrect.
 login: fred     <<< note note note note
 Password: <fred's password>
 machine2 fred $ _

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.

I don't know well about kerberos environment, but think that things
like this should be avioded specially.

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.

And one more note.  It seemed to be very bad idea to store tickets
somewhere in /tmp -- especially if we recall how many symlink attacks
and similar things has been corrected last time.
Home directory is better, but have other disadvantages, especially
in case it is nfs-mounted (that is common practice).  With nfs-mounted
homedir there are a lot of problems anyway (pgp/ssh private keys
that are passed via network in clear for example).

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?


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