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

Re: next version .44 or .5?



Michael K. Johnson wrote:
> Andrew Morgan writes:
> >
> > * libpam "enhanced" with the inclusion of a new return value (private
> >   to modules): PAM_FAIL_NOW, which can be used to terminate
> >   authentication (or other) stacks half way through. This should
> >   address the problem of root typing his password in the clear.
> 
> I thought that Marek addressed this very well in his post, I no
> longer think that we need anything like this.

Marek wrote:
: Another alternative (this is what the shadow login currently
: does): prompt for the password, but if it was correct, pretend
: that the authentication failed anyway (as if the password was
: wrong: sleep for a while, and print "Login incorrect") and log
: this fact as "ILLEGAL ROOT LOGIN" at LOG_CRIT priority.

Ooops! I guess I got ahead of myself and actually coded both the
PAM_FAIL_NOW and pam_fail_delay functions last night. I'll turn them
off with #ifdef PAM_FAIL_NOW_ON and #ifdef PAM_FAIL_DELAY_ON flags,
rather than delete them. That can be done later (when I get around to
tidying up the code for a "beta" release--whenever that is) at least
while Sun decides what *they* are going to do.

: The disadvantage is, of course, that it doesn't prevent typing
: the password over insecure channels, but then the legitimate
: admin probably knows that this tty is insecure - these secure
: tty restrictions were probably meant to stop intruders who got
: the root password some other way...

Sadly, there is also carelessness on the part of a sysadmin...

[ I still think that PAM_FAIL_NOW is a small price to pay, but I do
appreciate the point of trying to be compatibile... So feel free to
ignore the code. ]

Just to clarify the (official) Sun situatuion, here is the email I
received from Sun [anyone know what the GSS-API is?]:

charlie@pacific-85.Eng.Sun.COM wrote:
] > all of the authentication modules should
] > are tested in sequence independent of their pass/fail status
] 
] good point.  i guess, then, if we were to implement this in a module,
] it'd have to be a generic unix authentication module.  if the
] user is root, it checks the /etc/default/login file first.
] if the user is not root, normal authentication proceeds.
] 
] > 
] > > we're still left with the problem with the password going over in
] > > the clear.
] > 
] > Exactly.
] > 
] 
] if you think about it, we're really talking about single signon.
] this has been a real stickler for us.  one possible solution would
] be to initially login a user to a local host using PAM.
] 
] then applications that write to the GSS-API would perform
] any network authentication (krlogin or ktelnet for example?).
] 
] we feel that PAM is flexible enough to handle single-signon,
] but we're not sure exactly how this would be done.
] perhaps a module could just write to the GSS-API?
] we just haven't had the time to think through the different options yet.



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