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