Bug 178431
| Summary: | CVE-2006-2607 Jobs start from root when pam_limits enabled | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Roman Veretelnikov <roman> |
| Component: | vixie-cron | Assignee: | Jason Vas Dias <jvdias> |
| Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4 | CC: | k.georgiou, mattdm, tmraz |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 4.1-40.FC4 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-07-25 23:46:02 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I've now been able to investigate and have reproduced this problem. The problem is partly due to a PAM issue (bug?) : pam_limits.so, if a hard user nproc limit as configured in /etc/security/limits.conf, would be exceeded by a pam_open_session(...) call, continues to return PAM_SUCCESS if the user calling pam_open_session is root (this is not the user the limit is for). ie, in /etc/security/limits.conf, there is the line: user hard nproc 4 and in /etc/pam.d/crond or in system-auth is the line: session required pam_limits.so and vixie-cron does the pam_open_session as root, for the 'user' user. Then, after 4 non-terminating user processes have been forked, pam-0.79-9.6 continues to allow the pam_open_session to succeed, but then crond's subsequent setuid() to 'user's uid fails; the upstream vixie-cron-4.1 did not test for a failure of setuid, so crond is still root when the job is exec'd. Also, more forks() are allowed, even after the limit is exceeded . Yes, this is very bad. FC-5 Rawhide's vixie-cron-4.1-44.FC5 does test for the failure of the setuid() and does not have this problem. Interestingly, RHEL-3's pam-0.75-66's pam_limits does correctly fail the fork() when a user's nproc limit is exceeded; the kernel also emits message 'unable to load module net-pf-10: fork failed' whenever this occurs. RHEL-4's pam-0.77-66.14 also makes the fork() fail (not the initial setuid()), and allows no more processes than the user's nproc limit . So, problems occur when the fork()s do not fail, but the setuid()s do, as in FC-4; it is also difficult to understand why pam_limits allows the pam_open_session to succeed if the userid is root, and the limits for a non-root userid are violated, but then causes setuid() to fail, but not fork() - I think at least this is a PAM bug - if a user's nproc limit is exceeded, that user should not be able to fork() more processes. Anyway, this is now fixed with vixie-cron-4.1-40.EL4, which should be released to FC-4 updates/testing tomorrow. From User-Agent: XML-RPC vixie-cron-4.1-40.FC4 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. pam_limits doesn't enforce the limits this is clearly a job of the kernel. So maybe the root limits enforcement rules in kernel changed between RHEL4 and FC4 kernels? This was apparently fixed in an update (verified in the ftp tree) but never closed. Closing. |
From Bugzilla Helper: User-Agent: Opera/8.50 (Windows NT 5.0; U; ru) Description of problem: I set hard nproc limit in limits.conf to 10 and uncommented "session required pam_limits.so" in /etc/pam.d/crond When process limit have reached new processes start from root. Version-Release number of selected component (if applicable): vixie-cron-4.1-36.FC4 pam-0.79-9.6 How reproducible: Always Steps to Reproduce: 1. Add "username hard nproc 10" to /etc/security/limits.conf 2. Uncomment line with pam_limits.so in /etc/pam.d/crond 3. Add jobs in username crontab: * * * * * /path/to/script.pl script.pl: #!/usr/bin/perl open file, '>/path/to/pid.'.$$; close file; while(1) { sleep(1); } Actual Results: After some time "ps aux" shows 10 process of script.pl under the user username but other processes are under root. 10 pidfiles owned by username:usergroup but others by root:usergroup Expected Results: 10 processes of script.pl under username Additional info: Also applied to FC3