I think I may have a possible explanation for this issue, which seems to
point the blame at the kernel.
>From man setexeccon I see:
"setexeccon sets the context used for the next execve call. NULL
can be passed to setexeccon to reset to the default policy behavior.
The exec context is automatically reset after the next execve, so a
program doesn’t need to explicitly sanitize it upon startup.
setexeccon can be applied prior to library functions that internally
perform an execve, e.g. execl*, execv*, popen, in order to set an exec
context for that operation."
Reading the Cron source, I see the following sequence:
crond[parent] runs as crond_t
crond[[parent] reads /etc/crontab
crond[parent] forks a worker child still in crond_t
crond[child] setexeccon's to system_crond_t based on /etc/crontab
crond[child] forks a grandchild to run the Job in system_crond_t
crond[grandchild] execle()'s the actual job.itself,
which now runs in system_crond_t because of setexeccon().
crond[child] still in crond_t(?) waits for STDOUT pipe from Job.
crond[child] sees incoming STDOUT and fork()/evecvp()'s yet again
to run the sendmail process.
My reasoning has it that crond[child] forks sendmail as system_crond_t,
because it still has the latest setexeccon() setting leftover from
the creation of the grandchild. However, it NEEDS to have the
setexeccon() status left in place because it needs to run sendmail in
either system_mail_t or user_mail_t depending on whether it is a user
Cron Job or a system Cron Job.
Therefore, I reason, the bug is actually in the kernel which doesn't
allow for an exec() to perform a double transition. In this case, it
would need to jump from crond_t to system_crond_t ( because of
setexeccon() ), and thereafter to system_mail_t ( because of
domain_auto_trans in SELinux policy. ) all during the act of performing
a single exec().
Is this a plausible explanation for the observed behaviour?
If so, the workround is presumably for crond to double fork before
invoking the Job. i.e inside crond, do_command() would call
child_process(), which would then setexeccon(), then fork() AGAIN to
drop into the new security context as set by setexeccon(), and only then
build all the pipes and the greatgrandchild Job process and sendmail
processes themselves.
Ted
On Mon, 2007-02-12 at 10:14 +0000, Ted Rule wrote:
> 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
