Bug 178431 - CVE-2006-2607 Jobs start from root when pam_limits enabled
CVE-2006-2607 Jobs start from root when pam_limits enabled
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brock Organ
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-20 10:16 EST by Roman Veretelnikov
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 4.1-40.FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-25 19:46:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Roman Veretelnikov 2006-01-20 10:16:06 EST
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
Comment 1 Jason Vas Dias 2006-01-23 19:04:48 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.
Comment 2 Fedora Update System 2006-01-23 22:21:04 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.
Comment 3 Tomas Mraz 2006-01-24 04:27:11 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?
Comment 4 Matthew Miller 2006-07-25 19:46:02 EDT
This was apparently fixed in an update (verified in the ftp tree) but never
closed. Closing.

Note You need to log in before you can comment on or make changes to this bug.