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/
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
