Roger Bumgarner un jour écrivit:
I just tested this behavior on my Lenny/Sid workstation and Etch
server... frightening indeed! Lenny does spit out an error whereas
Etch still gives a password prompt.
Well, It is not that bad as It is usualy only exploitable localy. But
still certainly not the best behavior.
Also, It allows to guess if some application have been installed
without loggin in, because some application creates a user in /etc/passwd
however, since this happens at the login shell, I'd be more concerned
about a user booting a liveCD. I assume SSH still behaves correctly?
can someone verify?
It is all configured in PAM, and ssh use a different config file so It
is not affected.
To restore the original behaviour, just modify the file
/etc/pam.d/login by replacing the following line by the second:
#auth requisite pam_securetty.so
auth required pam_securetty.so
or even better (on a single line):
auth [success=ok new_authtok_reqd=ok ignore=ignore auth_err=die
service_err=die default=ignore] pam_securetty.so
You can look at man pam.d (5) and pam_securetty to understand
what It changes.
With the Lenny behaviour, someone who attempt by mistake to login as
root when using a tty (or equivalent) that has not been marked as trusted
in /etc/securetty will be prevented to enter the root password (actually
just strongly discouraged).
With the old behaviour, he/she would still have been able to type in
his password using a potentially untrusted channel, before seeing his
login attempt being denied anyway.
My guess is what they really wanted to do was something like the following:
auth [success=ok new_authtok_reqd=ok ignore=ignore auth_err=die
service_err=die default=ignore] pam_securetty.so
I only made some quick tests by disabling one tty in securetty, so you
should check It before trusting that It works as intended.
Simon Valiquette
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
