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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
