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

[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.