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.

Description of problem:
After upgrading to RHEL 6.4, fail2ban is unable to run iptables:
fail2ban.actions.action: ERROR  iptables -N fail2ban-SSH#012iptables -A fail2ban-SSH -j RETURN#012iptables -I INPUT -p tcp --dport ssh -j fail2ban-SSH returned 300

type=1400 audit(1362102917.292:143040): avc:  denied  { create } for  pid=25079 comm="iptables" scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=rawip_socket
type=1400 audit(1362102917.292:143041): avc:  denied  { read } for  pid=25079 comm="iptables" scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:sysctl_modprobe_t:s0 tclass=file

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.7.19-195.el6_4.1.noarch

Actually, that is only some of it.  The full policy I had to put in place to get the fail2ban iptables action to work cleanly is:

require {
	type insmod_exec_t;
	type sysctl_modprobe_t;
	type fail2ban_t;
	type modules_conf_t;
	type modules_object_t;
	class capability { net_admin net_raw };
	class dir { read search open };
	class file { read execute open execute_no_trans };
	class rawip_socket { getopt create setopt };
}

#============= fail2ban_t ==============
allow fail2ban_t insmod_exec_t:file { read execute open execute_no_trans };
allow fail2ban_t modules_conf_t:dir { read search open };
allow fail2ban_t modules_conf_t:file read;
allow fail2ban_t modules_object_t:dir search;
allow fail2ban_t self:capability { net_admin net_raw };
allow fail2ban_t self:rawip_socket { getopt create setopt };
allow fail2ban_t sysctl_modprobe_t:file read;

Created attachment 704049 [details]
AVCs generated by  fail2ban iptables action

It looks like fail2ban_t process did not transition to iptables_t domain. Could you check if BZ#916727 affects you too?

Milos,
yes, you are right.

*** This bug has been marked as a duplicate of bug 916727 ***