Cron mail problem with FC6/strict

[Ted Rule]

Since my previous posting on this matter, I've performed a few more
tests, slightly amended policy, and found a somewhat surprising result.

Because earlier tests indicated that individual Jobs could initiate mail
themselves from system_crond_t, but NOT crond itself, I reasoned that
maybe there was perhaps something in one or all of  policy / crond /
libselinux / kernel which prevented crond - which had already performed
a setexeccon - to exec another process which directly required a domain
transition.

Therefore, I made use of crond's "-m" option to provide a shell wrapper
to sendmail itself employing the same command line params as crond
invokes, as in:


[root at topaz ~]# cat /usr/sbin/sendmail.sendmail.crond 
#!/bin/sh

/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t
[root at topaz ~]# 


I also labelled the wrapper as sendmail_exec_t:

[root at topaz ~]# ls -lZ /usr/sbin/sendmail.sendmail*
-rwxr-sr-x  root smmsp
system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail
-rwxr-xr-x  root root
staff_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail.crond
[root at topaz ~]# 


Because of findings from previous tests, I added an entrypoint to
SELinux policy which appears to be required:


       domain_entry_file(system_crond_t, sendmail_exec_t)


And then I invoked the wrapper via /etc/sysconfig/crond:

[root at topaz ~]# cat /etc/sysconfig/crond 
# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
# CRON_VALIDATE_MAILRCPTS=1:a non-empty value of this variable will
#                           enable vixie-cron-4.1's validation of 
#                           mail recipient names, which would then be
#                           restricted to contain only the chars
#                           from this tr(1) set : [@!:%-_.,:alnum:]
#                           otherwise mailing is not attempted.
#CRONDARGS=
CRONDARGS="-m/usr/sbin/sendmail.sendmail.crond"
[root at topaz ~]# 


With all this in place, I found that Crond COULD launch the wrapper
script, which in turn launched sendmail itself, and Cron mail WAS
delivered.

If I simply comment out the CRONDARGS setting to revert crond to
"normal" operation, it succeeds in executing /usr/sbin/sendmail, but
fails to transition to system_mail_t and no mail is delivered.

As a next test, I further emulated /usr/sbin/sendmail itself by adding
group membership, setgid flags and selinux ownership:

[root at topaz ~]# ls -lZ /usr/sbin/sendmail.*
-rwxr-sr-x  root smmsp
system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail
-rwxr-sr-x  root smmsp
system_u:object_r:sendmail_exec_t /usr/sbin/sendmail.sendmail.crond
[root at topaz ~]# 


This still appears to work Ok. 


All in all, I appear to have a workround for the problem. It DOES seem
to require one tweak to the existing policy - the extra
domain_entry_file setting. However, I'm still very much in the dark as
to why the wrapper script works and the binary copy of sendmail doesn't.
 


Ted




On Wed, 2007-01-24 at 10:19 +0000, Ted Rule wrote:
> Quoting "Christopher J. PeBenito" <cpebenito at tresys.com>:
> 
> > On Sun, 2007-01-21 at 23:05 +0000, Ted Rule wrote:
> >> A little while ago, I found that anacron wasn't running correctly under
> >> FC6/strict, which led to me add a temporary fixup .te for its operation.
> >> Once I had that in place, I finally received the cron.daily and logwatch
> >> Emails every day shortly after bootup.
> >>
> >> With that in place, I recently took to leaving the machine powered
> >> overnight, which of course led to all the Cron jobs running via crond
> >> instead of anacron.
> >>
> >> Oddly, I noticed that the logwatch Email arrived, but NOT the cron.daily
> >> summary Email.
> >>
> >> Looking further, I found this odd avc:
> >>
> >> Jan 21 21:29:51 topaz kernel: audit(1169414991.423:988): avc:  denied
> >> { entrypoint } for  pid=4891 comm="crond" name="sendmail.sendmail"
> >> dev=hda6 ino=1313020
> >> scontext=system_u:system_r:system_crond_t:s0-s0:c0.c1023
> >> tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
> >>
> >> i.e. the crond child process running in system_crond_t was apparently
> >> unable to run sendmail.
> >
> > Is this supposed to be cron emailing the output of the cron jobs or the
> > cron job itself emailing something?
> 
> The former: as mentioned above, my tests indicate that the latter seems 
> to work
> Ok.
> 
> As far as I can tell, what happens is that crond starts in
> crond_t, forks a crond child, setexeccon's to system_crond_t to run the 
> Job, and
> then forks a sendmail process to pick up the stdout/stderr from the 
> Job. Hence I
> think you end up with something like this:
> 
> 101 crond_t              crond
> 102 system_crond_t          \ crond
> 103 system_crond_t             \ cron-job-script
> 104 system_mail_t              \ sendmail
> 
> where stdout/stderr from the cron-job-script is routed into the 
> sendmail stdin,
> with email subject line and similar parameters injected from pid 102. I also
> believe that pid 104 is not created at all until some output is generated by
> pid 103 - hence silent Cron Jobs don't create the avc denials for sendmail.
> 
> sendmail directly or indirectly launched by pid 103 is Ok according to 
> my tests,
> but seemingly sendmail launched by pid 102 itself gronks.
> 
> 
> >
> > --
> > Chris PeBenito
> > Tresys Technology, LLC
> > (410) 290-1411 x150
> >
> >
> 

-- 
Ted Rule

Director, Layer3 Systems Ltd

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