+++ This bug was initially created as a clone of Bug #178431 +++ 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 -- Additional comment from jvdias on 2006-01-23 19:04 EST -- 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. -- Additional comment from updates.com on 2006-01-23 22:21 EST -- 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. -- Additional comment from tmraz on 2006-01-24 04:27 EST -- 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 issue should also affect RHEL2 and RHEL3.
This issue will be RHSA-2006:0539
Here is an additional patch from OpenBSD which adds a few extra checks. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/cron/do_command.c.diff?r1=1.26&r2=1.27
Thanks, Josh - I've checked that all issues dealt with in the OpenBSD patch are dealt with in vixie-cron-4.1-40.EL4+ . I've rebuilt vixie-cron as vixie-cron-4.1-44.EL4 and tested this issue again - all tests pass. I'll attach the vixie-cron-4.1-44.EL4 packages to the errata.
Jason, Does this issue affect RHEL 2 and 3 as well?
No, this issue does not affect RHEL-2 or RHEL-3. It does not directly affect RHEL-4 either, as I noted in bug 178431: " 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 . " But it's definitely a good idea to test the return values of setgid(), setuid(), and initgroups also which the upstream vixie-cron did not do.
Since this bug does not affect the current RHEL-4 vixie-cron-4.1-36.EL4 version, I'm closing it as 'NOTABUG'. The fixes to test the return values of setgid(), setuid(), and initgroups() are definitely a good idea and nice to have, but as the lack of such checks does not give rise to this security vulnerability in RHEL-4, they should be considered enhancements, and will go in with the next vixie-cron RHEL-4 update.
This issue does affect RHEL4 after all. Right now we have the pam_limits.so line commented out for RHEL4. This simply makes this bug harder to exploit, but still possible. The 2.6 kernel sets an arbitrary nproc limit for each user (it's based off the amount of memory a machine has). Once this limit is hit, the cron job will run as root (the setuid fails). For easy testing just uncomment the pam_limits line in the crond pam configuration file.
I still cannot reproduce this problem at all on RHEL-4. Here is how I've been testing it - please let me know if I'm missing something . With vixie-cron-4.1-36.EL4 installed : 1. It is unecessary to comment out the 'session required pam_limits.so' from /etc/pam.d/crond, since by default /etc/pam.d/system-auth (used by the pam_stack.so required by /etc/pam.d/crond) includes that line. However, I also tested uncommenting the 'session required pam_limits.so' from /etc/pam.d/crond explicitly, and was unable to reproduce the problem. So, with or without the pam_limits line in /etc/pam.d/crond, I get the same results: 2. As root, create user 'user', with default group membership # useradd user 3. As root, restart cron: # service crontab restart 4. As root, enable hard nproc limits for user user - in /etc/security/limits.conf: '... user hard nproc 4 ...' 5. As user, create cron job that never terminates: $ echo '* * * * * logger "USER JOB $$ "`id -a`; while /bin/true; do sleep 10; logger "USER JOB $$ STILL HERE!"; done' | crontab 6. As root, tail the /var/log/cron and /var/log/messages files. ONLY the first run of the 'user' job succeeds. We see in /var/log/cron: Jul 5 11:10:39 jvdspc crontab[5279]: (user) REPLACE (user) Jul 5 11:12:01 jvdspc crond[5311]: (user) CMD (logger "USER JOB $$ "`id -a`;while /bin/true; do sleep 10; logger "USER JOB $$ STILL HERE!"; done) Jul 5 11:13:01 jvdspc crond[5339]: (user) CMD (logger "USER JOB $$ "`id -a`;while /bin/true; do sleep 10; logger "USER JOB $$ STILL HERE!"; done) Jul 5 11:13:02 jvdspc crond[5338]: (user) MAIL (mailed 48 bytes of output but got status 0x0001 ) As the last line shows, the second run failed (since the fork failed), so the job produced error output which cron was unable to mail for the same reason. In /var/log/messages, we see only ONE startup line from the user job: Jul 5 11:12:02 jvdspc logger: USER JOB 5311 uid=10446(user) gid=10446(user) groups=10446(user) context=user_u:system_r:unconfined_t and after twenty minutes of cron attempting to run the user job every minute, only the initial first job is still running : # ps -ef | grep user user 5251 5250 0 11:10 pts/4 00:00:00 -bash user 5311 5310 0 11:12 ? 00:00:00 /bin/sh -c logger "USER JOB $$ "`id -a`;while /bin/true; do sleep 10; logger "USER JOB $$STILL HERE!"; done user 26871 5311 0 11:33 ? 00:00:00 sleep 10 Indeed, user's bash session cannot run anything because of the hard nproc limit: [user@jvdspc ~]$ which ls -bash: fork: Resource temporarily unavailable On Fedora, before the fix for bug 178431 was applied, the fork() would not fail, only the setuid()/setgid() would fail, causing the serious security issue - so, once again, THERE IS NO SERIOUS SECURITY ISSUE CAUSED BY THIS BUG IN RHEL-3 OR RHEL-4 . So, as I cannot reproduce this bug on RHEL-4, I am closing as 'NOTABUG'. If you can find a way to reproduce it with vixie-cron-4.1-36.EL4 on RHEL-4, then please append full step-by-step details, log messages, and ps output as above, showing the problem, and re-open this bug - thanks.
Here is how to reproduce this. This issue does not affect RHEL3, but it does affect RHEL4. I have a user called 'test' with a hard nproc limit of 4 set. Here is my crontab entry: * * * * * chown root.root /tmp/bash && chmod 4755 /tmp/bash [root@localhost ~]# ps auwwx | fgrep test root 3757 0.4 0.4 4736 1236 pts/0 S 14:45 0:00 su - test test 3758 0.6 0.5 5304 1372 pts/0 S 14:45 0:00 -bash test 3784 0.3 0.5 5732 1372 pts/0 S 14:45 0:00 bash test 3802 0.3 0.5 5728 1372 pts/0 S 14:45 0:00 bash test 3825 0.2 0.5 5224 1312 pts/0 S+ 14:46 0:00 bash [root@localhost ~]# ls -l /tmp/bash -rwxr-xr-x 1 test nobody 616312 Jul 5 14:38 /tmp/bash (time passes) [root@localhost ~]# ls -l /tmp/bash -rwsr-xr-x 1 root root 616312 Jul 5 14:38 /tmp/bash
Now fixed with new vixie-cron-4.1-44.EL4 packages, respun with only the fixes for this bug.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0539.html