Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
SELinux blocks sadc from writing data to an arbitrary location from a root cron job; for example, running a command like "/usr/libc/sa/sadc 1 5 /opt/sartest" from cron will fail with an AVC. This only fails in this way from cron -- root can execute the same command in the shell with no problem. Even granting the unlikely case of an attacker who can create cron jobs but who can't get to a shell prompt, it's trivial to subvert this limitation even in cron with something like "/usr/libc/sa/sadc 1 5 | cat > /opt/sartest" (SELinux has made useless uses of cat less useless...).
So this SELinux-imposed limitation is breaking standard functionality without providing any security. Generally speaking, sadc is not a dangerous network daemon but just a utility that produces a file as output -- conceptually not much different from touch, cp, cat, etc, none of which are limited in this particular way by SELinux in root cron jobs (clearly "cp /etc/shadow /opt/shadow" is infinitely more dangerous than this sadc example, but it works just fine from a root cron job).
So I'd suggest that the standard Redhat SELinux policy should be changed to permit root cron jobs to write sadc data in any arbitrary location (just as they've always been able to do).
Version-Release number of selected component (if applicable):
selinux-policy*-3.7.19-155.el6_3
How reproducible:
Create a root cron job that attempts to place sadc output anywhere other than /var/log/{atsar,sa,sysstat}
Steps to Reproduce:
1. Add a file to /etc/cron.d with contents "* * * * * root /usr/lib64/sa/sadc 1 5 /opt/sartest"
Actual results:
An AVC like the following:
Jul 17 22:41:01 sadserver kernel: type=1400 audit(1342590061.835:7): avc: denied { write } for pid=12063 comm="sadc" name="opt" dev=dm-0 ino=1177345 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=dir
Expected results:
sadc writes the output file.
Miroslav we can remove the transition, so the job would stay running as an uncnfined job. Since I do not even know what sadc is for, the policy was probably written to allow cron jobs to work on a tightly locked down system. Maybe the correct option is to make sadc an unconfined domain and then don't worry about it. It would then work in a confined sense for MLS or machines without unconfined.pp but would not block john.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2013-0314.html
Description of problem: SELinux blocks sadc from writing data to an arbitrary location from a root cron job; for example, running a command like "/usr/libc/sa/sadc 1 5 /opt/sartest" from cron will fail with an AVC. This only fails in this way from cron -- root can execute the same command in the shell with no problem. Even granting the unlikely case of an attacker who can create cron jobs but who can't get to a shell prompt, it's trivial to subvert this limitation even in cron with something like "/usr/libc/sa/sadc 1 5 | cat > /opt/sartest" (SELinux has made useless uses of cat less useless...). So this SELinux-imposed limitation is breaking standard functionality without providing any security. Generally speaking, sadc is not a dangerous network daemon but just a utility that produces a file as output -- conceptually not much different from touch, cp, cat, etc, none of which are limited in this particular way by SELinux in root cron jobs (clearly "cp /etc/shadow /opt/shadow" is infinitely more dangerous than this sadc example, but it works just fine from a root cron job). So I'd suggest that the standard Redhat SELinux policy should be changed to permit root cron jobs to write sadc data in any arbitrary location (just as they've always been able to do). Version-Release number of selected component (if applicable): selinux-policy*-3.7.19-155.el6_3 How reproducible: Create a root cron job that attempts to place sadc output anywhere other than /var/log/{atsar,sa,sysstat} Steps to Reproduce: 1. Add a file to /etc/cron.d with contents "* * * * * root /usr/lib64/sa/sadc 1 5 /opt/sartest" Actual results: An AVC like the following: Jul 17 22:41:01 sadserver kernel: type=1400 audit(1342590061.835:7): avc: denied { write } for pid=12063 comm="sadc" name="opt" dev=dm-0 ino=1177345 scontext=system_u:system_r:sysstat_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=dir Expected results: sadc writes the output file.