RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1039644 - SELinux is preventing /usr/sbin/clamd from name_bind access on the tcp_socket
Summary: SELinux is preventing /usr/sbin/clamd from name_bind access on the tcp_socket
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.5
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-09 16:50 UTC by Frank Wang
Modified: 2014-10-14 07:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1248785 (view as bug list)
Environment:
Last Closed: 2014-10-14 07:58:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
sample sealert information (1.00 KB, text/plain)
2013-12-09 16:50 UTC, Frank Wang 		no flags Details
The clamd raw audit log (97.90 KB, application/x-targz)
2013-12-10 09:26 UTC, Frank Wang 		no flags Details
local selinux policy installed before upgrade (3.81 KB, application/zip)
2013-12-10 13:59 UTC, Frank Wang 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1568 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2014-10-14 01:27:37 UTC

Description Frank Wang 2013-12-09 16:50:32 UTC 
Created attachment 834395 [details]
sample sealert information

Description of problem:
After upgrading to realease 6.5, clamd starts to fail handling any incoming mail and raising above selinux denials. As the source port is randomly selected by clamd, it's not possible to use sealert suggestion "grep clamd /var/log/audit/audit.log | audit2allow -M mypol" to work around the problem.

Version-Release number of selected component (if applicable):
selinux-policy-3.7.19-231.el6.noarch
selinux-policy-targeted-3.7.19-231.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1.Install release 6.4 and config a mail server using clamd from EPEL as antivirus tool in the mail process chains. Verify mail sending/receiving works as expected and Eicar test attachment can be tagged correctly by the clamd.
2.Upgrade to release 6.5
3.Send any mail containing eicar test attachment to the server.

Actual results:
selinux denial raises like above and clamd fails to tag eicar test mail. The antivirus subsystem is actually down.

Expected results:
no selinux denial and clamd tags mail correctly.

Additional info:
In my case, clamd uses default config and is used by dspam.conf as following,
ClamAVPort              3310
ClamAVHost              127.0.0.1
ClamAVResponse          spam
Comment 1 Frank Wang 2013-12-09 16:58:24 UTC 
clamd-0.98-2.el6.x86_64
dspam-3.10.2-4.el6.x86_64
Comment 2 Miroslav Grepl 2013-12-10 07:53:06 UTC 
Could you please attach raw AVC message from /var/log/audit/audit.log.
Comment 3 Frank Wang 2013-12-10 09:26:51 UTC 
Created attachment 834668 [details]
The clamd raw audit log

If any further info required, please let me know.
Comment 4 Frank Wang 2013-12-10 13:59:36 UTC 
Created attachment 834777 [details]
local selinux policy installed before upgrade

These types were compiled and installed to make the mail system works with selinux before upgrade.
Comment 5 Frank Wang 2014-05-16 07:53:40 UTC 
The selinux-policy-targeted is updated to 3.7.19-231.el6_5.3, and it's still the same. I had found a similar problem in BZ#1015819 which says glusterfsd using random local port blocking by selinux. That one was fixed.
Comment 6 Frank Wang 2014-05-20 09:05:54 UTC 
    I've found a workaround from the clamd side to the problem. There're port range limiting settings in the /etc/clamd.conf. I set them as following,
vi /etc/clamd.conf
    ...
    StreamMinPort 30000
    StreamMaxPort 30099

   Then label the source port range as selinux suggests,
for i in `seq 30000 30099`; do
	echo $i
	semanage port -a -t clamd_port_t -p tcp $i 
done
service clamd start
vi /etc/dspam.conf
    ...
    ClamAVPort 3310
    ClamAVHost 127.0.0.1
    ClamAVResponse spam
service clamd reload

    Now, selinux won't complain and virus detection works as expected. 
    I think there's a problems for this workaround. As the OS could randomly choose source ports for other applicatons in the server, what if they're in the set range above that is not used by clamd? Then selinux will treat them from source domain clamd_port_t and probably blocks them.
Comment 7 Miroslav Grepl 2014-05-20 12:09:40 UTC 
Ok we need to add specific RHEL6 fixes to the policy for this case.
Comment 8 Lukas Vrabec 2014-06-09 12:49:15 UTC 
I sent patch to Miroslav.
Comment 11 errata-xmlrpc 2014-10-14 07:58:23 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1568.html
Note You need to log in before you can comment on or make changes to this bug.