Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
Click here to see the post LQ members have rated as the most helpful post in this thread.
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...
[root@linadmin1 pam.d]# cat login
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth include system-auth
account required pam_nologin.so
account include system-auth
password include system-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session include system-auth
session required pam_loginuid.so
session optional pam_console.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open
session optional pam_keyinit.so force revoke
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:
this does not resolve the issue. I figured removing the nullok_secure option would suffice, but it does not??
and
Code:
auth required pam_unix.so
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??
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."
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...
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?
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.
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
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 :-/
Last edited by amonamarth; 01-26-2010 at 01:17 AM.
Reason: revision
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.
Quote:
password - specifies the module that allows users to change their password (if appropriate) ~Wale Soyinka
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.
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.