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