getting denials when run from init script but not from command-line

[Johnny Tan]

I took the Fedora-8 SRPM for rsyslog 2.0.2 and rebuilt it 
for CentOS-5 x86_64. After doing:

# semanage fcontext -a -t syslogd_exec_t /sbin/rsyslogd
# semanage fcontext -a -t klogd_exec_t /sbin/rklogd

I can do "service rsyslog start" and it works.


Then, I did the rebuild for rsyslog version 3.11.6. Had to 
tweak the spec and conf files a bit, but got it packaged and 
installed. And made sure the above contexts were retained 
(they were).

However, when I go to run it "service rsyslog start" using 
the same init script that worked with the 2.0.2 version, I 
get this:

==
type=SYSCALL msg=audit(03/05/2008 17:43:26.966:224) : 
arch=x86_64 syscall=bind success=yes exit=0 a0=1 a1=51b2ae0 
a2=10 a3=7fffa9e3f63c items=0 ppid=29717 pid=29718 auid=root 
uid=root gid=root euid=root suid=root fsuid=root egid=root 
sgid=root fsgid=root tty=(none) comm=rsyslogd 
exe=/sbin/rsyslogd subj=root:system_r:syslogd_t:s0 key=(null)
type=AVC msg=audit(03/05/2008 17:43:26.966:224) : avc: 
denied  { node_bind } for  pid=29718 comm=rsyslogd src=61514 
scontext=root:system_r:syslogd_t:s0 
tcontext=system_u:object_r:inaddr_any_node_t:s0 
tclass=tcp_socket
==


BUT, when I run it directly from the command-line:
/sbin/rsyslogd
I do NOT get those denials.

I know how to create the module to allow the above, but what 
I'm more interested in is what allows me to run it from the 
command-line but not from the init script.

The line that starts the rsyslogd in the init script is:
         daemon rsyslogd $SYSLOGD_OPTIONS
("daemon" being a function sourced from /etc/init.d/functions)

But even if I replace that line with a simple:
/sbin/rsyslogd
it still gives me the denials.


Anyone have ideas why? I don't want to just create the 
module and sweep this under the rug.


Here's the full start() function section of the 
/etc/init.d/rsyslog:

start() {
         [ -x /sbin/rsyslogd ] || exit 5

         # Source config
         if [ -f /etc/sysconfig/rsyslog ] ; then
                 . /etc/sysconfig/rsyslog
         else
                 KLOGD_OPTIONS="-2"
         fi

         if [ -z "$SYSLOG_UMASK" ] ; then
               SYSLOG_UMASK=077;
         fi
         umask $SYSLOG_UMASK

         echo -n $"Starting system logger: "
         daemon rsyslogd $SYSLOGD_OPTIONS
         RETVAL=$?
         echo
         [ $RETVAL -eq 0 ] && touch /var/lock/subsys/rsyslog
         return $RETVAL
}


Thanks,
johnn

[Paul Howarth]

Johnny Tan wrote:
>  I took the Fedora-8 SRPM for rsyslog 2.0.2 and rebuilt it for
> CentOS-5 
>  x86_64. After doing:
>  
>  # semanage fcontext -a -t syslogd_exec_t /sbin/rsyslogd
>  # semanage fcontext -a -t klogd_exec_t /sbin/rklogd
>  
>  I can do "service rsyslog start" and it works.
>  
>  
>  Then, I did the rebuild for rsyslog version 3.11.6. Had to tweak the 
>  spec and conf files a bit, but got it packaged and installed. And made 
>  sure the above contexts were retained (they were).
>  
>  However, when I go to run it "service rsyslog start" using the same init 
>  script that worked with the 2.0.2 version, I get this:
>  
>  ==
>  type=SYSCALL msg=audit(03/05/2008 17:43:26.966:224) : arch=x86_64 
>  syscall=bind success=yes exit=0 a0=1 a1=51b2ae0 a2=10 a3=7fffa9e3f63c 
>  items=0 ppid=29717 pid=29718 auid=root uid=root gid=root euid=root 
>  suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) 
>  comm=rsyslogd exe=/sbin/rsyslogd subj=root:system_r:syslogd_t:s0 key=(null)
>  type=AVC msg=audit(03/05/2008 17:43:26.966:224) : avc: denied  { 
>  node_bind } for  pid=29718 comm=rsyslogd src=61514 
>  scontext=root:system_r:syslogd_t:s0 
>  tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket
>  ==
>  
>  
>  BUT, when I run it directly from the command-line:
>  /sbin/rsyslogd
>  I do NOT get those denials.
>  
>  I know how to create the module to allow the above, but what I'm more 
>  interested in is what allows me to run it from the command-line but not 
>  from the init script.
>  
>  The line that starts the rsyslogd in the init script is:
>          daemon rsyslogd $SYSLOGD_OPTIONS
>  ("daemon" being a function sourced from /etc/init.d/functions)
>  
>  But even if I replace that line with a simple:
>  /sbin/rsyslogd
>  it still gives me the denials.
>  
>  
>  Anyone have ideas why? I don't want to just create the module and sweep 
>  this under the rug. 
This is normal behaviour for confined daemons (those that policy has 
been written for); they transition to their own domain (syslogd_t in 
this case) and are confined to that domain when run from the initscript 
but don't transition and run unconfined if you start them directly from 
the command line.

Paul.

[Johnny Tan]

Paul Howarth wrote:
>  Johnny Tan wrote:
> > I took the Fedora-8 SRPM for rsyslog 2.0.2 and rebuilt it for CentOS-5 
> > x86_64. After doing:
> >
> > # semanage fcontext -a -t syslogd_exec_t /sbin/rsyslogd
> > # semanage fcontext -a -t klogd_exec_t /sbin/rklogd
> >
> > I can do "service rsyslog start" and it works.
> >
> >
> > Then, I did the rebuild for rsyslog version 3.11.6. Had to tweak the 
> > spec and conf files a bit, but got it packaged and installed. And made 
> > sure the above contexts were retained (they were).
> >
> > However, when I go to run it "service rsyslog start" using the same 
> > init script that worked with the 2.0.2 version, I get this:
> >
> > ==
> > type=SYSCALL msg=audit(03/05/2008 17:43:26.966:224) : arch=x86_64 
> > syscall=bind success=yes exit=0 a0=1 a1=51b2ae0 a2=10 a3=7fffa9e3f63c 
> > items=0 ppid=29717 pid=29718 auid=root uid=root gid=root euid=root 
> > suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) 
> > comm=rsyslogd exe=/sbin/rsyslogd subj=root:system_r:syslogd_t:s0 
> > key=(null)
> > type=AVC msg=audit(03/05/2008 17:43:26.966:224) : avc: denied  { 
> > node_bind } for  pid=29718 comm=rsyslogd src=61514 
> > scontext=root:system_r:syslogd_t:s0 
> > tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket
> > ==
> >
> >
> > BUT, when I run it directly from the command-line:
> > /sbin/rsyslogd
> > I do NOT get those denials.
> >
> > I know how to create the module to allow the above, but what I'm more 
> > interested in is what allows me to run it from the command-line but 
> > not from the init script.
> >
> > The line that starts the rsyslogd in the init script is:
> >         daemon rsyslogd $SYSLOGD_OPTIONS
> > ("daemon" being a function sourced from /etc/init.d/functions)
> >
> > But even if I replace that line with a simple:
> > /sbin/rsyslogd
> > it still gives me the denials.
> >
> >
> > Anyone have ideas why? I don't want to just create the module and 
> > sweep this under the rug.
>  
>  This is normal behaviour for confined daemons (those that policy has 
>  been written for); they transition to their own domain (syslogd_t in 
>  this case) and are confined to that domain when run from the initscript 
>  but don't transition and run unconfined if you start them directly from 
>  the command line. 
Thanks Paul. I guess what got me is that version 2.0.2 did 
not exhibit this behavior, even when ran from the *same* 
init script. Shouldn't it also have been confined and, 
hence, generate the same AVC denials?

Secondly, so I guess if this is "normal" behavior, then I 
*should* be creating and loading the module to allow the 
tcp_socket connect that's currently being denied for the 
v3.11.6 daemon. Correct?

Thanks for the insight,
johnn

[Paul Howarth]

Johnny Tan wrote:
>  Paul Howarth wrote:
> > Johnny Tan wrote:
> >> I took the Fedora-8 SRPM for rsyslog 2.0.2 and rebuilt it for 
> >> CentOS-5 x86_64. After doing:
> >>
> >> # semanage fcontext -a -t syslogd_exec_t /sbin/rsyslogd
> >> # semanage fcontext -a -t klogd_exec_t /sbin/rklogd
> >>
> >> I can do "service rsyslog start" and it works.
> >>
> >>
> >> Then, I did the rebuild for rsyslog version 3.11.6. Had to tweak the 
> >> spec and conf files a bit, but got it packaged and installed. And 
> >> made sure the above contexts were retained (they were).
> >>
> >> However, when I go to run it "service rsyslog start" using the same 
> >> init script that worked with the 2.0.2 version, I get this:
> >>
> >> ==
> >> type=SYSCALL msg=audit(03/05/2008 17:43:26.966:224) : arch=x86_64 
> >> syscall=bind success=yes exit=0 a0=1 a1=51b2ae0 a2=10 a3=7fffa9e3f63c 
> >> items=0 ppid=29717 pid=29718 auid=root uid=root gid=root euid=root 
> >> suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) 
> >> comm=rsyslogd exe=/sbin/rsyslogd subj=root:system_r:syslogd_t:s0 
> >> key=(null)
> >> type=AVC msg=audit(03/05/2008 17:43:26.966:224) : avc: denied  { 
> >> node_bind } for  pid=29718 comm=rsyslogd src=61514 
> >> scontext=root:system_r:syslogd_t:s0 
> >> tcontext=system_u:object_r:inaddr_any_node_t:s0 tclass=tcp_socket
> >> ==
> >>
> >>
> >> BUT, when I run it directly from the command-line:
> >> /sbin/rsyslogd
> >> I do NOT get those denials.
> >>
> >> I know how to create the module to allow the above, but what I'm more 
> >> interested in is what allows me to run it from the command-line but 
> >> not from the init script.
> >>
> >> The line that starts the rsyslogd in the init script is:
> >>         daemon rsyslogd $SYSLOGD_OPTIONS
> >> ("daemon" being a function sourced from /etc/init.d/functions)
> >>
> >> But even if I replace that line with a simple:
> >> /sbin/rsyslogd
> >> it still gives me the denials.
> >>
> >>
> >> Anyone have ideas why? I don't want to just create the module and 
> >> sweep this under the rug.
> >
> > This is normal behaviour for confined daemons (those that policy has 
> > been written for); they transition to their own domain (syslogd_t in 
> > this case) and are confined to that domain when run from the 
> > initscript but don't transition and run unconfined if you start them 
> > directly from the command line.
>  
>  Thanks Paul. I guess what got me is that version 2.0.2 did not exhibit 
>  this behavior, even when ran from the *same* init script. Shouldn't it 
>  also have been confined and, hence, generate the same AVC denials? 
My guess is that this is new behaviour in 3.11.6 that wasn't there in 
2.0.2, and hence no denials for the old version.

>  Secondly, so I guess if this is "normal" behavior, then I
> *should* be 
>  creating and loading the module to allow the tcp_socket connect that's 
>  currently being denied for the v3.11.6 daemon. Correct? 
I would say so, though I'd check the documentation for the new version 
to see what it's actually doing with this socket.

Paul.