I was working on a server where the customer was using ClamAV and Stream Ports to check for viruses. They had a problem where the server would not accept their connection. The logfiles for the error showed up like:

Sun Jan  1 08:00:03 2012 -> ERROR: ScanStream 1088: accept() failed.

At first I thought it was a firewall rule, but after looking things over it looked ok. In my googling, I noticed a lot of people had problems with SELinux and since this system did in fact run SELinux, I started looking at those logfiles. I found the following errors (formatted for readability):

type=AVC msg=audit(1326835719.949:35310855): avc:  denied  { name_bind } for
    pid=4901 comm="clamd" src=1505 scontext=user_u:system_r:clamd_t:s0
    tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1326835719.949:35310855): arch=c000003e syscall=49
    success=no exit=-13 a0=c a1=415d0e50 a2=10 a3=41a705af1fe3fb79 items=0
    ppid=1 pid=4901 auid=4294967295 uid=3218 gid=3218 euid=3218 suid=3218
    fsuid=3218 egid=3218 sgid=3218 fsgid=3218 tty=(none) ses=4294967295
    comm="clamd" exe="/usr/sbin/clamd" subj=user_u:system_r:clamd_t:s0

This was one of my first rodeo’s with SELinux, so further research on the name_bind permission was necessary. I found that this occurs when an application tries to open a port they aren’t allowed to. I checked the SELinux configuration to see what ports it would allow ClamAV to open:

$ sudo semanage port -l | grep clamd
clamd_port_t tcp 3310

Bingo! The conf file for my client was defaulting to the streamports being open from 1024-2048, so I added that exception:

$ sudo semanage port -a -t clamd_port_t -p tcp 1024-2048 
$ sudo semanage port -l | grep 3310 
clamd_port_t tcp 1024-2048, 3310 

Once done, I tested…

$ telnet localhost 3310 Trying
Connected to localhost.localdomain (
Escape character is '^]'.
PORT 1246

And confirmed it worked!

Recovering a Juniper EX3400 after a failed zeroize

I recently zeroized[^1] a handful of EX3400s running 15.1X53-D55.5, and foundthat they would no longer properly boot into the kernel once...… Continue reading

Disabling IPv6 Privacy Extensions

Published on April 14, 2017

From RVM to rbenv (1 of 2)

Published on May 27, 2015