Regarding PAM_TTY_KLUDGE and Solaris 8...

Nicolas Williams Nicolas.Williams at ubsw.com
Fri Oct 26 05:50:29 EST 2001


On Thu, Oct 25, 2001 at 03:30:38PM -0400, Nicolas Williams wrote:
> On Thu, Oct 25, 2001 at 10:51:01AM -0700, Darren Moffat wrote:
> > It is up to the calling application and its' conversation function to
> > deal with getting the information from the user.  If pam_acct_mgmt
> > returns PAM_NEW_AUTHTOK_REQD and sshd isn't able to prompt the user for
> > one (because it has no tty) then it has to make its own choice of what
> > to do, it can continue and ignore it or it can display a warning or it
> > can disconnect - it is upto sshd to choose what to do (it could use
> > SSH_ASKPASS if it is available).
> 
> if pam_acct_mgmt() returns PAM_NEW_AUTHTOK_REQD and the application
> can't call pam_chauthtok() or do the subsequent prompting of the user
> then the app should NOT just go on.

That aside, it would be nice to have two standard PAM conversation
functions, one for conversing on a TTY, the other for conversing via
something like SSH_ASKPASS (or PAM_ASK_ITEM :)

> In the case of Kerberos password validation doing so would open the
> application to a major KDC spoofing attack. This is because there is
> nothing in the AS-REP to prove to the application that the response came
> from a valid KDC -- the host can only validate the KDC by getting a TGT
> and then a service ticket for a host principal for which that host has a
> valid key stored locally.
> 
> > --
> > Darren J Moffat
> 

Cheers,

Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the openssh-unix-dev mailing list