Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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
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.
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.
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.
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
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