Able to Locally Login as Root with ANY password??
 

Found a major security hole in one of my more crucial linux servers today. (Only locally) I can use the user name "root" and any string for the password. So I can literally type "poop" as the password and the server lets me in.
I know how to set root password settings for SSH and sudo, but where are settings located for local access that would allow something like this??
Thanks,
Dan

It depends on how do you access. Usually, nowadays, this is via pam on most regular distros. So, it's probably the pam config what you should be looking at.

Look first into /etc/passwd. There should be an entry for root (first column). It should start from
root:x
The 'x' means that there's a password in /etc/shadow. /etc/shadow should also have an entry for root, something starting from
root:somestring:
'somestring' is the password (not in plain form).

There's definitely a password for root, and it's used for everything else (SSH, Sudo, Su -, etc.).
I'm looking at PAM and I'm not sure what might be out of place...

tada.


And you thought Debian wasn't meant to be awful? http://www.redhat.com/archives/pam-l.../msg00001.html

Goodness gracious. Gotta love these obscure, poorly documented options.

I read that article earlier this morning, it left me even more confused!

I tried to test this by creating a test account, and actually the system denies access to both good and bad passwords. Ok, so it appears that is a separate issue. I just now tested this theory on another system that was having the same original problem, and changing the auth parameters to: works!

OK, so if I merely changed
to
this does not resolve the issue. I figured removing the nullok_secure option would suffice, but it does not??
and
works, does not allow for authentication over pam_krb5.so
So adding pam_deny.so allows for both sufficient modules but denies invalid password entries.

OK OK, so this is where I'm left feeling confused:
I was looking for the answer in the "password" module... why does the "auth" module have anything to do with verifying the password of an account??

that's an obscure issue indeed
 

I was recently studying this specific subject for my RHCE RH302 test. Quoting Michael Jang's book, RHCE Linux Study Guide(fifth edition), page 306:

"Authentication management(auth): Establishes the identity of the user [...] a PAM auth module command decides whether to prompt for a username and/or password."

What distribution are we talking about? And is this the default setup?

CentOS 5.4 yes, I believe it's the default set up. I've never made any modifications to PAM myself. Can anyone confirm this?
What I did notice today was the only servers that had this PAM configuration were those running as virtualized guests on an ESXi server...

That's definitely not the default setup for CentOS / RHEL. Look at the first line of your system-auth file, and you can see that someone has it under version control.

default setup
 

Hello:

That is NOT the default with CentOS 5.4.
I recently redid one of servers from scratch with CentOS 5.4
Here is how my file looks like: (KEEP READING AFTER IT)

--------------------------------------------------------------
[root@hostname pam.d]$ cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so

-------------------------------------------------------------

Notice the "try_first_pass" ending the second line. Referring to Michael Jang's book once again, it seems that this argument to the "auth" command "allows the use of a previous successful password."
But if that is the case, why my system works ok then?
Weird ... now I have questions lol I hope no hard issues about this in the test :-/

Ok, I figured out that the system-auth file was copied on install from a central config repository on my network - explains why all the newest servers are setup this way.

@amonamarth
Maybe the try_first_pass option causes +1 failed attempts and could cause issues if you set an account to lock out after so many tries? That's my educated guess.

I've been very mistaken, the password module does not have anything to do with initial authentication. So it's all in the auth module.

****I'm still confused on this last point. If this is my auth module stack, then if the root password is incorrect, it should be passed to pam_krb5.so which by the "requisite" (or "required") flag should terminate the login attempt.
This is showing not to be the case. I have to add the pam_deny.so
So I understand that pam_deny.so sends the failure code, but why is it needed, by my logic I feel like the stack should never proceed to that step in the first place! :(
Anyone have any ideas?
Thanks :)

From logs:

Found it.

at the top of my /etc/pam.d/login file. This line caused all local users logging in at the console to be allowed access regardless what was in the system-auth file.

I ran into some issues after I commented that line out, but they aren't of any concern to this discussion.

Not too sure what those options mean, but it appears that it checks the securetty file, which lists the console, thus returns a "success" and fulfills the authentication requirements. I'm assuming (and will try to research it more tomorrow) that the "user_unknown=ignore" argument is why non-local users had to have a valid password because their Active Directory account was not known to the stack at this stage.