The Silence of the Anacrons

[Daniel J Walsh]

Ted Rule wrote:
> The host is FC4 rather than FC5testN
>
> In order to avoid having to run in permissive overnight or completely
> reload the policy at the moment, I've run the following test:
>
> Create new directory /etc/anacron.daily and a corresponding entry
> in /etc/anacrontab. Create /etc/anacron.daily/0anacron and a test
> job /etc/anacron.daily/mailcheck.  ( See below )
>
> Run in enforcing by restarting anacron service with
>
> sudo service anacron start
>
> Wait 5 mins for Job to run, and note that the resultant Email is
> empty-bodied as with /etc/cron.daily
>
> Check anacron stopped.
>
> Delete the timestamp file /var/spool/anacron/anacron.daily
>
> Goto permissive with
>
> sudo setenforce 0
>
> Wait 5 mins for Job to run, and note that the resultant Email is
> properly formed with Subject and body as expected.
>
> Go back to enforcing.
>
> This all seems to confirm to me that SELinux policy is somehow blanking
> the body and subject. The only denial messages I see during in
> permissive state are these:
>
> Mar 15 15:12:53 topaz sudo:     ejtr : TTY=pts/1 ; PWD=/home/ejtr ;
> USER=root ; COMMAND=/sbin/service anacron start
> Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6922): avc:  denied
> { read write } for  pid=12151 comm="anacron" name="1" dev=devpts ino=3
> scontext=root:system_r:system_crond_t
> tcontext=user_u:object_r:user_devpts_t tclass=chr_file
> Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6923): avc:  denied
> { use } for  pid=12151 comm="anacron" name="1" dev=devpts ino=3
> scontext=root:system_r:system_crond_t tcontext=user_u:user_r:user_t
> tclass=fd
>
> which I think corresponds to the anacron processes being unable to write
> to the user_* FD's belonging to the shell which was used to invoke "sudo
> service". Since the AVC's are related to a user_* domain, I assume they
> are unrelated to the problem itself, which I imagine depends upon the
> interaction of the initrc_t, crond_t, and system_crond_t domains.
>
> I'll try and perform a similar test with an enableaudit policy as soon
> as I can. Obviously, the log may take a bit of weeding!
>
>
> ==============================
> $ cat /etc/anacrontab
> # /etc/anacrontab: configuration file for anacron
>
> # See anacron(8) and anacrontab(5) for details.
>
> SHELL=/bin/sh
> PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
> MAILTO=root
>
> 1       5       anacron.daily           run-parts /etc/anacron.daily
> 1       65      cron.daily              run-parts /etc/cron.daily
> 7       70      cron.weekly             run-parts /etc/cron.weekly
> 30      75      cron.monthly            run-parts /etc/cron.monthly
> $
>
> $ cat /etc/anacron.daily/0anacron
> #!/bin/sh
> #
> # anacron's cron script
> #
> # This script updates anacron time stamps. It is called through
> run-parts
> # either by anacron itself or by cron.
> #
> # The script is called "0anacron" to assure that it will be executed
> # _before_ all other scripts.
>
> anacron -u anacron.daily
>
> $ cat /etc/anacron.daily/mailcheck
> #!/bin/sh
>
> echo "Testing Anacron Mail system"
>
> cat /etc/resolv.conf
>
> $
>   
Please enter a bugzilla so we don't loose this.
>
>
> On Wed, 2006-03-15 at 08:51 -0500, Daniel J Walsh wrote:
>   
>> Ted Rule wrote:
>>     
>>> Something that's niggled me for a while are the empty Email messages
>>> generated by Anacron.
>>>
>>> This is on FC4 / selinux-policy-strict-1.27.1-2.22
>>>
>>> When the machine is left powered overnight, the normal /etc/cron.daily
>>> processes - including logwatch and logrotate - run perfectly happily and
>>> generate appropriate Emails.
>>>
>>> By default, logrotate doesn't result in an Email, but for reasons
>>> unrelated to SELinux I have it set to run in debug mode, so my instance
>>> does. The Email from logrotate is effectively 'sent' by /etc/cron.daily
>>> as it wrappers all the output from its child jobs.
>>>
>>> In contrast, logwatch sends its own Email independent of Cron's sendmail
>>> child process.
>>>
>>> When the machine is depowered overnight and repowered in the morning,
>>> Anacron proceeds to run the various /etc/cron.daily scripts. With
>>> SELinux enforcing, logwatch runs normally, and generates its normal
>>> Email log summary.
>>>
>>> However, logrotate's output is never seen, even though it can be seen
>>> from the various timestamps and filenames that logrotate has correctly
>>> run and suitably rotated all the logs.
>>>
>>> The overall cron.daily Job launched by Anacron results in an empty
>>> Email, with no body and more particularly no Subject. The mail From
>>> address is set to "Anacron <root at hostname>".
>>>
>>> Burrowing around the Anacron source it is apparent that under normal
>>> circumstances it would give the Email a subject of
>>>
>>> 	"Anacron job cron.daily"
>>>
>>> Given the behaviour I see, I think the problem is somehow related to
>>> the /etc/cron.daily/* processes not having rights to write to the file
>>> descriptor which is the input to Cron's overall sendmail process.
>>>
>>> I've had a look through the SELinux policy to see if I can spot the
>>> difference between the permissions of Jobs launched by Cron and Anacron,
>>> and I'm afraid I can't see where the problem lies; since jobs launched
>>> by either method appear to run as system_crond_t, the difference in
>>> behaviour eludes me.
>>>
>>> Can anyone else offer any insight into the problem?
>>>
>>> Thanks,
>>>
>>>
>>>
>>>   
>>>       
>> Is this on FC5?  If yes, are you seeing any AVC messages?  If not could 
>> you attempt to enable audit
>>
>> semodule -b /usr/share/selinux/targeted/enableaudit.pp
>>
>> Create the error.
>>
>> Grab the AVC Messages
>>
>> semodule -b /usr/share/selinux/targeted/base.pp
>>
>> to turn off auditing again.
>>
>>
>> Of course verifying this works with setenforce 0 would also help to make 
>> sure it is SELinux causing the problem.
>>
>>     
>
>