The Silence of the Anacrons
Ted Rule
ejtr at layer3.co.uk
Mon Mar 20 16:57:28 UTC 2006
Having run SELinux in enableaudit mode, I see this:
Mar 20 09:37:48 topaz kernel: audit(1142847445.519:9803): avc: denied
{ append } for pid=5507 comm="sendmail" name="fileVPVqYv" dev=hda10
ino=21 scontext=root:system_r:system_mail_t
tcontext=root:object_r:system_crond_tmp_t tclass=file
A partial workround is thus to add this to policy:
# tail domains/misc/localpolicy.te
...
allow system_mail_t { system_crond_tmp_t }:file { append };
#
Since sendmail has no legitimate reason to write to a system_crond_tmp_t
file, the original SELinux policy is "correct", and this is only a
workround.
After burrowing round the anacron source, I found that the problem
arises because of the "dual-use" of a file-descriptor. anacron creates a
temporary file, opens a file-descriptor read/write, unlinks the
temporary filename, and then passes the FD as stdout/stderr to Job's it
runs. Once the Jobs are complete, it passes the FD as stdin to sendmail.
The problem appears to be that SELinux complains when sendmail tries to
use an inherited FD with write-permissions to a system_crond_tmp_t file.
Because the filename is unlinked after the file is opened, simply
closing the FD and re-opening the temporary file read-only is not an
option - or at least not a completely trivial one.
As a patch, therefore, I've tweaked anacron to open the temporary file
twice - once write-only and once read-only - before unlinking the
filename. The read-only FD is redirected to stdin, the write-only FD is
closed, and stdout/stderr redirected to /dev/null before exec-ing
sendmail.
This now added to Bugzilla as #185973 with an associated patch detailed
therein.
On Thu, 2006-03-16 at 13:22 -0500, Daniel J Walsh wrote:
> 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.
> >>
> >>
> >
> >
>
--
Ted Rule
Director, Layer3 Systems Ltd
E: ejtr at layer3.co.uk
W: http://www.layer3.co.uk/
T: 020-8769-4484
More information about the selinux
mailing list