mailman, cron, /bin/sh (more on Re: restorecon vs. setfiles???)

[Tom London]

I did a FC2 install 'everything' and that seems to have turned on mailman
cron entries. Unfortuneately, the one that runs /var/mailman/cron/gate_news
(every 5 minutes!) fails and sends email to email with the report:

    Subject: Cron <mailman@dell> /usr/bin/python -S 
/var/mailman/cron/gate_news
    X-Cron-Env: <SHELL=/bin/sh>
    X-Cron-Env: <HOME=/var/mailman>
    X-Cron-Env: <PATH=/usr/bin:/bin>
    X-Cron-Env: <LOGNAME=mailman>
 
    execl: couldn't exec `/bin/sh'
    execl: Permission denied
 
The equivalent avc message is:

    May 21 12:00:00 dell kernel: audit(1085166000.890:0): avc:  denied  
{ transition } for     pid=7796 exe=/usr/sbin/crond path=/bin/bash 
dev=hdb3 ino=376840 scontext=system_u:system_r:crond_t 
tcontext=user_u:sysadm_r:sysadm_t tclass=process

The appropriate entry in crond.te (I think) is:
    can_exec(crond_t, shell_exec_t)

The labels for /bin/bash and /bin/sh are as follows (from a clean FC2 
install):
    -rwxr-xr-x+ root     root     system_u:object_r:shell_exec_t   bash
    lrwxrwxrwx+ root     root     system_u:object_r:bin_t          sh -> 
bash

Is the label for /bin/sh causing this to fail?

   tom

------------------------------------------------------------------------

    * /From/: Daniel J Walsh <dwalsh redhat com>
    * /To/: "Fedora SELinux support list for users & developers."
      <fedora-selinux-list redhat com>
    * /Subject/: Re: restorecon vs. setfiles
    * /Date/: Wed, 19 May 2004 15:17:50 -0400

------------------------------------------------------------------------
Stephen Smalley wrote:

    On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote:


        Looks like a bug in matchpathcon (Which is used buy restorecon).
        It is returning the wrong security context. I will send this to
        stephen. Basically looks like it is ignoring file type.


matchpathcon takes a pathname and optional file mode as input parameters
for matching against the file contexts configuration.  It doesn't
attempt to stat the file itself to obtain the mode because it is
sometimes used by programs that are creating new files (e.g. udev) and
want to know the context for the file they are about to create, so it
requires the caller to provide the mode.  restorecon currently passes 0
as the mode, so no mode matching is performed.


So this is a bug in restorecon; it needs to be changed to stat the file
and provide the mode.




policycoreutils-1.12-2 has two fixes for restorecon, it handles the 
symbolic link problem and ignores <<none>>.

Dan