The Silence of the Anacrons

Ted Rule ejtr at layer3.co.uk
Wed Mar 15 15:44:28 UTC 2006


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

$



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.
> 

-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/




More information about the fedora-selinux-list mailing list