getting denials when run from init script but not from command-line
Johnny Tan
linuxweb at gmail.com
Thu Mar 6 16:44:24 UTC 2008
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
More information about the fedora-selinux-list
mailing list