Description of problem: This happens for both i386 and x64. The system is integrated with OpenLDAP. Once adding pam_ccreds configuration entries in /etc/pam.d/system-auth file, every LDAP user would be able to log into RHEL4 with NO password, or any password, via the system console. This is a huge system security hole. The same issue is not found on RHEL5. Or am I missing something?? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Install a vanilla RHEL4 system. Then put in OpenLDAP client configuration .. 2. In /etc/pam.d/system-auth file, adding the following to this vanilla configuration file: auth [authinfo_unavail=ignore success=1 default=2] /lib/security/$ISA/pam_ldap.so use_first_pass auth [default=done] /lib/security/$ISA/pam_ccreds.so use_first_pass action=validate auth [default=done] /lib/security/$ISA/pam_ccreds.so action=store auth [default=bad] /lib/security/$ISA/pam_ccreds.so action=update Actual results: Every LDAP user would be able to log into RHEL4 with NO password, or any password, via the system console. Expected results: None of the above should ever happen. Additional info: Please fix this ASAP. I have to comment out the above 2 lines with pam_ccreds in them.
This seems like pam misconfiguration. Could you attach the whole system-auth? Also does it work right when you use these lines instead? auth [authinfo_unavail=ignore success=2 default=1] /lib/security/$ISA/pam_ldap.so use_first_pass auth [success=done default=die] /lib/security/$ISA/pam_ccreds.so use_first_pass action=validate auth [default=die] /lib/security/$ISA/pam_ccreds.so action=update auth optional /lib/security/$ISA/pam_ccreds.so action=store
Hi, I just tried, and it failed in the same way. I am attaching /etc/pam.d/system-auth file now, which is working for me. You can see I have to comment out those lines .. Thanks, Hai
Created attachment 329769 [details] The requested system-auth file, which is working for me ..
Created attachment 329785 [details] Proposed configuration file to be tested Could you please try this attached system-auth file?
It works much better than before. I can no longer login as any OpenLDAP user with no password on console, and when trying my own OpenLDAP userid and password, it is working for me. But there is still one issue: If I provided wrong password for my LDAP userid on console, then first time it would say "Login incorrect", and provide "login: " prompt again, if I type LDAP userid again, it would say "Login incorrect" right away, without bothering to provide Password prompt. The same thing would happen twice more. Is this normal?
Yes, unfortunately this is limitation of pam_stack which is used in RHEL-4 to call the system-auth file. You can try to add drop_items option to pam_stack in /etc/pam.d/login. This hidden option should fix this problem in pam_stack but it cannot be used by default because it potentially breaks other configurations of system-auth. Note that this option was added in the RHEL-4 Update 7 release of pam package (pam-0.77-66.25).
But this bug you mentioned, I would only encounter it after enabling pam_ccreds module. Another behavior I just noted is the SSH login, once I got the wrong password for the 1st time, it will always fail no matter whether you enter the right password or not after the 1st time fail attempt. It works fine if you got the password right for the 1st time. Is this the same bug? It seems you indicate that the add_items option might break other things, so it seems it is not a safe option for me. Also could you please explain why the new file you provided works while the one from me would cause this security risk? Thank you, Hai
(In reply to comment #8) > But this bug you mentioned, I would only encounter it after enabling pam_ccreds > module. Can you try to replace the line: auth [authinfo_unavail=ignore success=1 default=2] /lib/security/$ISA/pam_ldap.so use_first_pass with: auth [authinfo_unavail=ignore success=1 user_unknown=2 default=die] /lib/security/$ISA/pam_ldap.so use_first_pass It might help. > Another behavior I just noted is the SSH login, once I got the wrong password > for the 1st time, it will always fail no matter whether you enter the right > password or not after the 1st time fail attempt. It works fine if you got the > password right for the 1st time. Is this the same bug? Yes, this is exactly the same problem. > It seems you indicate that the add_items option might break other things, so it > seems it is not a safe option for me. > > Also could you please explain why the new file you provided works while the one > from me would cause this security risk? It's again the way pam library and pam_stack module work in the pam package in RHEL-4. There are many pecularities in their functionality most of them were fixed in RHEL-5 and especially the pam_stack module was deprecated and is not used by the pam configuration files anymore. Unfortunately we cannot backport the changes to RHEL-4 because it would break some existing possible configurations of system-auth. Generaly saying as soon as you modify the pam configurations by hand you have to test the configuration thoroughly so it does not do unexpected and security-breaking things. This is true especially for RHEL-4 pam package.
I just tried this one: auth [authinfo_unavail=ignore success=1 user_unknown=2 default=die] /lib/security/$ISA/pam_ldap.so use_first_pass It didn't help, still behaving the same way as before. Thanks, Hai
another interesting behavior per the bug you mentioned before: Password: Sorry, try again. Sorry, try again. Sorry, try again. sudo: 3 incorrect password attempts After entering the wrong password, I would get the above error messages ..
Another possible attempt - could you remove the try_first_pass option from pam_unix? Also the drop_items option of pam_stack should not break anything in your configuration so you might try it as well.
I am not sure why my last update did not show up here. So here again. Thank you!! Removing try_first_pass option from pam_unix works for me, it is working much better than before. For the drop_items option, we are using a lower version, which means I have to upgrade, and the rpm pam package had been modified a bit here, so there's unclear factor for me to upgrade it. But it is working fine so far by removing try_first_pass. Thanks! Hai
Hai, are all your issues resolved now with the configuration changes proposed by Tomas? If that is the case, we should remove security keyword here and rather make this an documentation RFE bug, as the pam_ccreds packages may benefit from some configuration examples, so it's less likely for users to unintentionally create insecure setups.
I've just tested this here (since I use openldap auth on my network) and can verify that Tomaz's system-auth works provided the pam_unix fix noted in comment 13 is applied (removal of try_first_pass). Authenticated with login, ssh, and sudo. To "simulate" a downed LDAP server, I commented out the pam_ldap call in auth and can immediately tell on subsequent logins that pam_ccreds is kicking in. Not being familiar with RHEL4 (yet), I don't know if the initial pam_ccreds configuration is something we did (i.e. some system-config task that sets that up?) or if the user did the configuration on his own. If some tool of ours did it, we likely need to handle it, but if this is simple misconfiguration on the user's part, then I think some documentation would suffice.
Answering my own question, authconfig does not add pam_ccreds calls to /etc/pam.d/system-auth; all it does is enable/start nscd. So this can be closed I think, after appropriate documentation is created.
Based on the comments above, changing this to documentation RFE bug... It would be good to include configuration examples in the pam_ccreds package, that would make it easier for users to configure this pam module correctly in their environments. As shown in this bug, incorrect configuration may result in insecure setups if not tested properly. Knowledge base article may be a viable (preferred?) alternative to adding additional documentation to the pam_ccreds packages. The additional benefit of the knowledge base article is that it is easier to cover configurations for multiple Red Hat Enterprise Linux versions, emphasizing the differences between versions.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
Sorry for being a bit slow but just for sure could someone please paste the final, working and secure configuration here so that everyone surely gets it right? FWIW, Ubuntu guide is here: https://help.ubuntu.com/community/PamCcredsHowto Probably wrong place to ask but doesn't this account entry let all cases pass through? account [authinfo_unavail=ignore default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
Created attachment 334108 [details] The final working configuration This is the final working configuration, it differs from the proposed one just by removing the try_first_pass option from pam_unix in auth. The account entry for pam_ldap is OK, we have to ignore the return value if the module does not know anything about the user or when the module cannot reach the server.
Thanks, I can confirm that the configuration attached to comment #20 works. I did a lots of testing and everything seemed to be in order (except for one bizarre corner case). To summarize: when connected, successful login creates/stores to cache. When connected and unsuccessful login occurs, cache is not touched. When disconnected, cache is never touched. The bizarre corner case I noticed was the following, causing the cache entry for the user to be removed: service ldap on <login with correct pw> <see how creds stored> logout service ldap off <try login with incorrect pw> service ldap on <login with correct pw> <see how cache entry removed, login fails!> <login with correct pw> <see how no creds stored, login fails!> <see how no creds stored, login fails!> <login with correct pw> <now works ok> I was logging in from console and in case of consequent logins the previous prompts stayed in the screen, if I let some time to pass and those prompts to get cleaned, then everything works as expected. For me this doesn't matter, but just letting you know that in the worst case a user could need to four login attempts with correct password to get in :-)
Sure would be nice if we could develop and example for RHEL5 now too.