There are a few ways that you could speed up your troubleshooting:

1. Schedule your job with a file in /etc/cron.d to run the script in /etc/cron.daily on a much more frequent interval
2. Use runcon to run your script with the same context that crond would have when executing.  For example:
          runcon -u system_u -r system_r -t system_cronjob_t /etc/cron.daily/logrotate

After you run the scripts (or at the end of the scripts), can you run this and provide the raw audit messages?
          ausearch -m avc -ts recent


On Thu, Aug 14, 2014 at 8:17 AM, Shaw, Ray V CTR USARMY ARL (US) <ray.v.shaw.ctr@mail.mil> wrote:
Classification: UNCLASSIFIED
Caveats: NONE

Background info: running RHEL6 with the latest updates, so selinux-policy-targeted-3.7.19-231.el6_5.3.noarch.

When moving from Permissive to Enforcing, two scripts in /etc/cron.daily that use the bash "." operator to include a functions file can no longer do so.  The functions file sets $PATH and other environment variables, so subsequent commands in the scripts fail.

Interestingly, when run out of root's crontab, the scripts work just fine.  The context when doing that (gathered by placing id -Z in the script) is:

unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Not sure why; the script itself isn't unlabeled:

bash-4.1# ls -lZ /usr/local/sbin/puppet-state
-rwx------. root root system_u:object_r:bin_t:s0       /usr/local/sbin/puppet-state

When run from /etc/cron.daily (or cron.hourly, where I placed a copy for faster testing), the context is:

system_u:system_r:system_cronjob_t:s0-s0:c0.c1023

bash-4.1# ls -lZ /etc/cron.hourly/puppet-state
-rwx------. root root system_u:object_r:bin_t:s0       /etc/cron.hourly/puppet-state

The exact command in question it's failing to run is:

. /opt/puppet/scripts/functions

Which is labeled thusly:

bash-4.1# ls -lZ /opt/puppet/scripts/functions
-r-x------. root root unconfined_u:object_r:usr_t:s0   /opt/puppet/scripts/functions

In either Enforcing or Permissive, I wasn't seeing anything that looked relevant, so I ran semodule -DB.  This is the only thing cron-related, but (and I'm not very experienced with SELinux, so maybe I'm missing something) that doesn't seem like it:

bash-4.1# cat /var/log/audit/audit.log-20140814 | grep cron | audit2allow -w
type=AVC msg=audit(1407915503.212:155119): avc:  denied  { rlimitinh } for  pid=26239 comm="prelink" scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process

        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1407915503.212:155119): avc:  denied  { siginh } for  pid=26239 comm="prelink" scontext=system_u:system_r:prelink_cron_system_t:s0-s0:c0.c1023 tcontext=system_u:system_r:prelink_t:s0-s0:c0.c1023 tclass=process

        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

I suppose we could run them out of root's crontab, but they're easier to manage in cron.daily, and I'd like to solve the problem.  Any assistance is greatly appreciated.  A search of the list archives didn't turn up this issue; sorry if I've missed it.

--
Ray Shaw (Contractor, STG)
Army Research Laboratory

Classification: UNCLASSIFIED
Caveats: NONE


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux



--
Jeremy Young, M.S., RHCSA