Description of problem: Version-Release number of selected component (if applicable): at-3.1.8-84.el5 selinux-policy-2.4.6-345.el5 selinux-policy-devel-2.4.6-345.el5 selinux-policy-minimum-2.4.6-345.el5 selinux-policy-mls-2.4.6-345.el5 selinux-policy-strict-2.4.6-345.el5 selinux-policy-targeted-2.4.6-345.el5 How reproducible: always Steps to Reproduce: 1. get a RHEL-5.10 machine 2. switch it from targeted policy to strict policy 3. log in as root/sysadm_r 4. # setenforce 1 5. # echo '/usr/bin/id -Z' | at now + 1 minute 6. # tail -f /var/log/messages Actual results: Jul 16 06:28:01 pes-guest-88 atd[5957]: Exec failed for mail command: Permission denied Jul 16 06:31:00 pes-guest-88 atd[6034]: Exec failed for mail command: Permission denied Jul 16 06:48:00 pes-guest-88 atd[6211]: Exec failed for mail command: Permission denied Expected results: * the command is successfully executed by atd * no error messages * no AVCs Additional info: Because atd program contains a bug, which cannot be fixed or worked around in selinux-policy, following AVC appears in enforcing mode: ---- type=SYSCALL msg=audit(07/16/2013 06:48:00.964:105) : arch=x86_64 syscall=execve success=no exit=-13(Permission denied) a0=2b8a651e94b9 a1=7fffc6d538b0 a2=7fffc6d560d8 a3=0 items=0 ppid=6207 pid=6211 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=7 comm=atd exe=/usr/sbin/atd subj=system_u:system_r:crond_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(07/16/2013 06:48:00.964:105) : avc: denied { entrypoint } for pid=6211 comm=atd path=/usr/sbin/sendmail.sendmail dev=dm-0 ino=7643742 scontext=root:sysadm_r:sysadm_crond_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file ----
Yes, the problem is with execl(ATD_MAIL_PROGRAM, ATD_MAIL_NAME, mailname, (char *) NULL); where setexeccon is not set for the default policy behavior and it runs with setexeccon(user_context)
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Could you explain me why no-one noticed such essential fault in behaviour before? I don't think such bugs or components will be approved so late in RHEL-5 time frame. I would close it.
Maybe there is a lack of customers/users who use atd and strict policy at the same time. The problem does not exist on machines running targeted policy.
In that case wontfix. I won't believe at will be approved component so late in support cycle. Although it may be good to add this test case in regression tests and verify if it doesn't fail on RHEL-6 and higher releases.