RE: cron issues with bash source (UNCLASSIFIED)

[Shaw, Ray V CTR USARMY RDECOM ARL (US)]

Classification: UNCLASSIFIED
Caveats: NONE

Attached.  I did notice some cron + bash related messages, so hopefully the 
answer is in there.  They seemed to refer to our su wrapper, which I admit 
could be the problem, if cron is calling su in some way.  I believe it's 
needed for some form of 2-factor authentication when using su.  It was 
previously labeled as unconfined; yesterday I changed the labeling to match 
that of the su binary in the original RHEL6 coreutils package, but that didn't 
seem to help.  I also tried reinstalling coreutils and using the standard su 
binary, but that didn't help either (I just get the same messages for "su" 
instead of "su.real").

bash-4.1# ls -lZ /bin/su*
lrwxrwxrwx. root root unconfined_u:object_r:bin_t:s0   /bin/su -> 
/bin/su.wrapper
-r-xr-xr-x. root root system_u:object_r:su_exec_t:s0   /bin/su.real
-r-sr-xr-x. root root system_u:object_r:su_exec_t:s0   /bin/su.wrapper

The attached file shows the commands run both with and without dontaudit 
disabled:

10:12:30  runcon -u system_u -r system_r -t system_cronjob_t 
/etc/cron.daily/puppet-state
10:14:25  semodule -B
10:15:06  runcon -u system_u -r system_r -t system_cronjob_t 
/etc/cron.daily/puppet-state
10:15:16  ausearch -m avc -ts recent &> /root/avc3.txt

--
Ray Shaw (Contractor, STG)
Army Research Laboratory
CIO, Unix Support


>  -----Original Message-----
>  From: Jeremy Young [mailto:[e-mail]]
>  Sent: Thursday, August 14, 2014 9:43 AM
>  To: Shaw, Ray V CTR USARMY ARL (US)
>  Cc: selinux(a)lists.fedoraproject.org
>  Subject: Re: cron issues with bash source (UNCLASSIFIED)
>
>  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(a)mail.mil&gt; 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(a)lists.fedoraproject.org
>  	https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
>
>
>  --
>
>  Jeremy Young <mailto:[e-mail]> , M.S., RHCSA
>
>  

Classification: UNCLASSIFIED
Caveats: NONE