Curious AVC for syslog-ng listening on non-standard TCP Port.
Ted Rule
ejtr at layer3.co.uk
Sat Jul 10 20:36:30 UTC 2010
In the course of trying to get a syslog-ng daemon running on a
non-standard TCP port on CentOS5, I came across an AVC for the port
which appeared
to already have a permission in the SELinux Policy.
We tried to make syslog-ng listen on TCP Port 5514, and as a result we
got the following set of audit messages:
$ sudo ausearch -ts yesterday -c syslog-ng
----
time->Fri Jul 9 23:04:26 2010
type=SYSCALL msg=audit(1278713066.242:269066): arch=40000003 syscall=102
success=no exit=-13 a0=2 a1=bfb34210 a2=95b51e8 a3=6 items=0 ppid=1
pid=1713 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="syslog-ng" exe="/sbin/syslog-ng"
subj=system_u:system_r:syslogd_t:s0 key=(null)
type=AVC msg=audit(1278713066.242:269066): avc: denied { name_bind }
for pid=1713 comm="syslog-ng" src=5514
scontext=system_u:system_r:syslogd_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
----
time->Fri Jul 9 23:04:26 2010
type=ANOM_ABEND msg=audit(1278713066.291:269067): auid=4294967295 uid=0
gid=0 ses=4294967295 subj=system_u:system_r:syslogd_t:s0 pid=1713
comm="syslog-ng" sig=11
----
time->Fri Jul 9 23:27:59 2010
type=SYSCALL msg=audit(1278714479.797:269169): arch=40000003 syscall=102
success=no exit=-13 a0=2 a1=bffe96d0 a2=97a6928 a3=6 items=0 ppid=1
pid=15354 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=44818 comm="syslog-ng" exe="/sbin/syslog-ng"
subj=user_u:system_r:syslogd_t:s0 key=(null)
type=AVC msg=audit(1278714479.797:269169): avc: denied { name_bind }
for pid=15354 comm="syslog-ng" src=5514
scontext=user_u:system_r:syslogd_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
----
time->Fri Jul 9 23:27:59 2010
type=ANOM_ABEND msg=audit(1278714479.833:269170): auid=500 uid=0 gid=0
ses=44818 subj=user_u:system_r:syslogd_t:s0 pid=15354 comm="syslog-ng"
sig=11
$
However, despite the fact that the AVC suggested that we needed to add
the permission:
allow syslogd_t port_t : tcp_socket { name_bind name_connect };
an sesearch suggests that the permission already exists:
$ sudo sesearch --allow -s syslogd_t | grep tcp |grep name.bind
allow syslogd_t rsh_port_t : tcp_socket { name_bind name_connect };
allow syslogd_t syslogd_port_t : tcp_socket { name_bind name_connect };
allow syslogd_t port_t : tcp_socket { name_bind name_connect };
allow syslogd_t reserved_port_t : tcp_socket { name_bind name_connect };
$
Eventually, we repaired the situation by adding TCP/5514 as a
syslogd_port_t, as in:
$ sudo semanage port -l |grep 514
cluster_port_t tcp 5149, 40040, 50006, 50007, 50008
cluster_port_t udp 5149, 50006, 50007, 50008
rsh_port_t tcp 514
syslogd_port_t tcp 5514
syslogd_port_t udp 514
virt_port_t tcp 16509, 16514
virt_port_t udp 16509, 16514
$
But my curiousity is piqued. Why did the policy deny the binding to a
type port_t, when the policy appeared to already allow this?
FWIW, the policy at the moment is a somewhat aged:
selinux-policy-targeted-2.4.6-203.el5
--
Ted Rule
Director, Layer3 Systems Ltd
http://www.layer3.co.uk/
More information about the selinux
mailing list