On Sun, Aug 24, 2008 at 03:01:41PM +0200, Nicolas François wrote: > On Sat, Aug 23, 2008 at 10:30:59PM -0700, [EMAIL PROTECTED] wrote: > > I just upgraded one of my sid machines that had a modified /etc/pam.d/login, > > and was quite surprised to see the conffile prompt from this change, > > specifically because of the use of pam_faildelay.
> > Did you consider doing this instead for pam_securetty?: > > auth [success=ok user_unknown=ignore default=die] pam_securetty.so > I did not added this because in case of an insecure TTY, if root enters > his name with a typo, she will be prompted for a password. > (That was my true in my last try: the user is checked before the TTY) True, but I'm not convinced this is actually a problem; in order for the user to shoot themselves in the foot, they must: - be running login on an insecure tty (...seriously? who still runs telnet anymore, unless it's kerberized telnet?) - mistype the name "root" - fail to *notice* they've mistyped the name "root", and then proceed to type the root password. Is that really a case that's worth protecting against? Isn't it just as likely that a user will type in a *correct* username, and then make the mistake of typing the root password instead of the user password? > There are in fact two contradicting requests on insecure TTYs > * if the user is unknown, the password prompt should not be displayed (it > might be a typo for root) > * the password prompt should always be displayed to avoid giving > an indication that the user does not exist. > I'm not sure which one is the most critical. I don't know either, but the previous behavior was consistent for the better part of a decade, so I think it would be preferable to have such a change discussed more widely (= debian-devel) before committing to it in a release. (I'm not happy with the new behavior of pam_securetty, myself, but I'm not going to diverge from the upstream change when we can work around it in the config as described above.) > > Not sure if that should be considered any better, but it avoids needing to > > add another module to the stack. (One which isn't very well documented, if > > I do say so myself!) > The additional pam_faildelay module replaces a call to pam_fail_delay() > which was removed from login (this was done to avoid hardcoding a delay in > login (it was in fact in login.defs), which was disturbing for user > willing to reduce the delay in login.defs, or to remove the delay by > adding nodelay to pam_unix). > Would it be better to call pam_faildelay only in case of a pam_securetty > failure, and otherwise let pam_unix set the delay? All in all, I think that calling pam_faildelay is appropriate because there are authentication modules one might use in place of pam_unix which do *not* call pam_fail_delay at all (e.g., pam_krb5 and pam_ldap). I'm just not sure that /etc/pam.d/login is the right place for it, or if it actually belongs in /etc/pam.d/common-auth. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
