Bug 223894
| Summary: | [LSPP] crontab doesn't report an error when a job is to be run above the user's level | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Matt Anderson <mra> |
| Component: | vixie-cron | Assignee: | Marcela Mašláňová <mmaslano> |
| Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.0 | CC: | dwalsh, iboverma, klaus, krisw, linda.knippers, sgrubb |
| Target Milestone: | --- | Keywords: | OtherQA |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2007-0564 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-11-07 18:36:41 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 224041 | ||
|
Description
Matt Anderson
2007-01-22 22:31:04 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? 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. 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. 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. 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. (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? Vixie cron should call the audit message at the same place as it calls the syslog to send the failure message. Fixed in vixie-cron-4:4.1-66.2 Patch is applied in version vixie-cron-4:4.1-74 in rawhide. per 2/12, need to build this and audit packages in RHEL. Fixed in vixie-cron-4.1-66.2.el5 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 |