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

[Johnny Tan <linuxweb gmail com>]

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