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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux