> 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:
VALID - user's credentials are authenticated and the user is
authorized to gain access to the specified account either
because the credentials are mapped to the account; or
because the account's owner has specified by a .k5login
or other mechanism that the user is authorized.
USER - user's credentials are authenticated but those credentials
map to an account other than the account the user is
requesting to login as. The user is not authorized to
access the account without proving knowledge of the
password which may now be transmitted over an encrypted
connection.
OTHER - user's credentials are authenticated but they do not
map to an account and the user did not request an account
to check for authorization. User must specify account
name and provide password to access. Encrypted connection
is still in use.
UNKNOWN- A form of anonymous login. The credentials provided
do not provide any identification of who the user is.
They are simply a means to exchange information necessary
for encrypting the session. User must providing account
and password for login.
> I don't know well about kerberos environment, but think that things
> like this should be avioded specially.
You can avoid this in your environment by configuring telnetd to
require VALID logins.
> 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.
> 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).
Home directory is unacceptable. Credential caches are not encrypted
and therefore cannot be transmitted over network mounts. /tmp/ is
assumed to be local to the machine. That is why it is used.
the use of the home directory to store pgp/ssh private keys is one of
the reasons I have been stating for years that SSH public key
authorization is not secure and a significant security hole just
waiting to be exploited.
Until we have a memory based cache for Unix /tmp will have to do.
> 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.
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
