Re: Root login

[Simon Valiquette <v.simon@ieee.org>]

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