Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 223894 - [LSPP] crontab doesn't report an error when a job is to be run above the user's level
Summary: [LSPP] crontab doesn't report an error when a job is to be run above the user...
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vixie-cron
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Marcela Mašláňová
QA Contact: Brock Organ
Depends On:
Blocks: RHEL5LSPPCertTracker
TreeView+ depends on / blocked
Reported: 2007-01-22 22:31 UTC by Matt Anderson
Modified: 2009-06-19 13:07 UTC (History)
6 users (show)

Fixed In Version: RHBA-2007-0564
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-11-07 18:36:41 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0564 normal SHIPPED_LIVE vixie-cron bug fix and enhancement update 2007-10-30 23:03:57 UTC

Description Matt Anderson 2007-01-22 22:31:04 UTC
Description of problem:
When I create a test user limited to just SystemLow and make a crontab entry for
them with the variable MLS_LEVEL=SystemHigh the command does not run (which is
expected) but it also never shows up in the audit log as a failure.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a SystemLow only user
2. run crontab -e
3. Add MLS_LEVEL=SystemHigh to the top of the crontab
4. Add an entry for the `id` command to run in a minute or so from now
5. Save and close the file
6. wait for it to run
Actual results:
This is the only audit message I get after the cronjob runs:
type=USER_ACCT msg=audit(1169504701.267:4062): user pid=14606 uid=0
auid=4294967295 subj=system_u:system_r:crond_t:s0-s15:c0.c1023 msg='PAM:
accounting acct=eal2 : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron

Expected results:
When I change the MLS_LEVEL=SystemHigh argument to SystemLow I get these audit
type=USER_ACCT msg=audit(1169504821.281:4063): user pid=14644 uid=0
auid=4294967295 subj=system_u:system_r:crond_t:s0-s15:c0.c1023 msg='PAM:
accounting acct=eal2 : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron
type=CRED_ACQ msg=audit(1169504821.282:4064): user pid=14644 uid=0
auid=4294967295 subj=system_u:system_r:crond_t:s0-s15:c0.c1023 msg='PAM: setcred
acct=eal2 : exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'
type=LOGIN msg=audit(1169504821.282:4065): login pid=14644 uid=0 old
auid=4294967295 new auid=502
type=USER_START msg=audit(1169504821.283:4066): user pid=14644 uid=0 auid=502
subj=system_u:system_r:crond_t:s0-s15:c0.c1023 msg='PAM: session open acct=eal2
: exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=success)'

Comment 1 Klaus Heinrich Kiwi 2007-01-22 23:26:48 UTC
From what I know I think that crond actually checks if the context is valid
before attempting a transition (which would cause a AVC message denying it)

Check /var/log/cron for 'invalid context' type messages - would that be
sufficient for the evaluation or we still need audit messages?

Comment 2 Matt Anderson 2007-01-23 15:53:12 UTC
Looking in /var/log/cron I did find these messages:
Jan 22 17:25:01 cert-x1 crond[14606]: CRON (eal2) ERROR:Unauthorized range
user_u:user_r:user_crond_t:SystemHigh in MLS_LEVEL for user
Jan 22 17:25:01 cert-x1 crond[14606]: CRON (eal2) ERROR: failed to change
SELinux context
Jan 22 17:25:01 cert-x1 crond[14606]: CRON (eal2) ERROR: cannot set security context

Given the following permissions:
-rw-------  root root system_u:object_r:var_log_t:SystemLow /var/log/cron

This may meet the requirements for the evaluation.

Comment 3 Matt Anderson 2007-01-23 17:03:35 UTC
It turns out logging unsuccessful attempts to change to a level to a cron log
file is not going to meet our requirements.  For one thing, all the required
information is not addressed by these log entries.  Additionally this log file
does not have the same on disk protection as the audit trail.

Comment 4 Marcela Mašláňová 2007-01-24 14:08:48 UTC
So what's the expected result of your problem? 
Cron is writing to /var/log/cron correct error message, because cron checks
permission for context before executing a job.

Comment 5 Matt Anderson 2007-01-24 15:56:29 UTC
Since this is an attempt to violate the MLS range of the user, by having cron
run the process on their behalf, we need an audit of the event.  Errors can
still go to /var/log/cron as well, but there also needs to be an audit of the

Comment 6 Klaus Heinrich Kiwi 2007-01-24 16:20:34 UTC
(In reply to comment #5)

Agree with Matt. But changing this would require profound changes to the way
vixie-cron is working, wouldn't it?

Another thing to note is that crojobs currently runs within the
'{prefix}_crond_t' domain - can't it run with the same exact type of the
submitting user? How to maintain the exact set of policy rules for {prefix}_t
and {prefix}_crond_t?

Comment 8 Daniel Walsh 2007-02-01 14:14:57 UTC
Vixie cron should call the audit message at the same place as it calls the
syslog to send the failure message.

Comment 9 Daniel Walsh 2007-02-06 18:52:54 UTC
Fixed in vixie-cron-4:4.1-66.2

Comment 10 Marcela Mašláňová 2007-02-07 13:38:07 UTC
Patch is applied in version vixie-cron-4:4.1-74 in rawhide.

Comment 11 Irina Boverman 2007-02-14 20:46:42 UTC
per 2/12, need to build this and audit packages in RHEL.

Comment 12 Daniel Walsh 2007-02-14 21:01:32 UTC
Fixed in vixie-cron-4.1-66.2.el5

Comment 18 errata-xmlrpc 2007-11-07 18:36:41 UTC
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.

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