Bug 223894 - [LSPP] crontab doesn't report an error when a job is to be run above the user's level
[LSPP] crontab doesn't report an error when a job is to be run above the user...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vixie-cron (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
: OtherQA
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-01-22 17:31 EST by Matt Anderson
Modified: 2009-06-19 09:07 EDT (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2007-0564
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 13:36:41 EST
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 Matt Anderson 2007-01-22 17:31:04 EST
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:
Everytime

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
res=success)'

Expected results:
When I change the MLS_LEVEL=SystemHigh argument to SystemLow I get these audit
results:
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
res=success)'
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 18:26:48 EST
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 10:53:12 EST
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
user_u:user_r:user_crond_t:SystemLow 
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 12:03:35 EST
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 09:08:48 EST
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 10:56:29 EST
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
failure.
Comment 6 Klaus Heinrich Kiwi 2007-01-24 11:20:34 EST
(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 09:14:57 EST
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 13:52:54 EST
Fixed in vixie-cron-4:4.1-66.2
Comment 10 Marcela Mašláňová 2007-02-07 08:38:07 EST
Patch is applied in version vixie-cron-4:4.1-74 in rawhide.
Comment 11 Irina Boverman 2007-02-14 15:46:42 EST
per 2/12, need to build this and audit packages in RHEL.
Comment 12 Daniel Walsh 2007-02-14 16:01:32 EST
Fixed in vixie-cron-4.1-66.2.el5
Comment 18 errata-xmlrpc 2007-11-07 13:36:41 EST
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/RHBA-2007-0564.html

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