Cron mail problem with FC6/strict

[Ted Rule]

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. 

Just to be curious, I added this permission:

auditallow system_crond_t sendmail_exec_t:file execute

and saw this:

Jan 21 21:30:51 topaz kernel: audit(1169415051.521:993): avc:  granted
{ execute } for  pid=4909 comm="crond" name="sendmail.sendmail" dev=hda6
ino=1313020 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
Jan 21 21:30:51 topaz kernel: audit(1169415051.521:994): avc:  denied
{ entrypoint } for  pid=4909 comm="crond" name="sendmail.sendmail"
dev=hda6 ino=1313020

i.e. crond was apparently allowed to execute sendmail but got caught
with the 'entrypoint' denial slightly later on.

As an added test, I created a per-minute Cron Job which itself
invoked /bin/mail which in turn called sendmail and a few invocations of
sleep (the sleeps just to make it slightly easier to read the process
list changes). 

Jan 21 21:31:11 topaz kernel: audit(1169415071.651:996): avc:  granted
{ execute } for  pid=4938 comm="mail" 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
Jan 21 21:31:11 topaz kernel: audit(1169415071.651:997): avc:  granted
{ read execute } for  pid=4938 comm="sendmail" 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
Jan 21 21:31:51 topaz kernel: audit(1169415111.704:999): avc:  granted
{ execute } for  pid=4947 comm="crond" name="sendmail.sendmail" dev=hda6
ino=1313020 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file
Jan 21 21:31:51 topaz kernel: audit(1169415111.704:1000): avc:  denied
{ entrypoint } for  pid=4947 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 call the sendmail from system_crond_t within the Cron job by
something other than the crond binary itself worked Ok, but when crond
tried to invoke, it just sulked.

If I went to permissive mode the log was filled with avc's indicating
that crond's direct invocation of sendmail failed to transition to
system_mail_t, even though these two interface calls appear to exist in
the policy:

mta_send_mail(crond_t)
mta_send_mail(system_crond_t)


For both anacron and crond launched invocations of cron.daily/0logwatch,
of course, logwatch itself invokes sendmail from logwatch_t, so the
problem doesn't arise.

I'm currently using selinux-policy-strict-2.4.6-27


I also tried adding this permission:

allow system_crond_t sendmail_exec_t:file entrypoint

but this didn't really help; crond:system_crond_t stubbornly refused to
transition to system_mail_t.

Since all the invocations from within Jobs running as system_crond_t and
also from anacron running as system_crond_t invoked sendmail Ok, my
presumption is that there's something in crond's own use of libselinux
which is confusing matters and preventing Email's being created.

Looking at the policy source a little bit more,

mta_send_mail() calls domain_auto_trans() which in turn calls
domain_trans().

Way back in FC4 policy, I can see that domain_trans()'s definition
contains an entry that suggests I actually need to add

allow system_mail_t sendmail_exec_t:file entrypoint

since the entrypoint permission appears to take the child_domain's
type as its first parameter, (which itself implies that the log entry is
slightly awry, just to be confusing...):

domain_trans(parent_domain, program_type, child_domain)
...
allow $3 $2:file entrypoint;

The FC6 policy source seems to have no automatic entrypoint permission
within the domain_trans() definition but does have the
domain_entry_file() interface.

Just for fun, therefore, I tried adding this:

domain_entry_file(system_mail_t, sendmail_exec_t)

All to no avail, I'm afraid; I continue to be unable to get crond to
directly execute sendmail.


Can anyone enlighten me, please?


-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/
-- 
Ted Rule

Director, Layer3 Systems Ltd

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