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

[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