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@topaz ~]# cat /usr/sbin/sendmail.sendmail.crond
#!/bin/sh
/usr/sbin/sendmail -FCronDaemon -i -odi -oem -oi -t
[root@topaz ~]#
I also labelled the wrapper as sendmail_exec_t:
[root@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@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@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@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@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@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(a)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/