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

Re: PAM and Kerberos



> 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






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