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 1290705 - SELinux prevents ipset from creating a netlink socket
Summary: SELinux prevents ipset from creating a netlink socket
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.7
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Simon Sekidde
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-11 08:32 UTC by Milos Malik
Modified: 2016-05-10 20:03 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-3.7.19-288.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-10 20:03:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0763 0 normal SHIPPED_LIVE selinux-policy bug fix update 2016-05-10 22:33:46 UTC

Description Milos Malik 2015-12-11 08:32:02 UTC
Description of problem:
 * seen on i686 and x86_64 machines

Version-Release number of selected component (if applicable):
selinux-policy-3.7.19-285.el6.noarch
selinux-policy-doc-3.7.19-285.el6.noarch
selinux-policy-minimum-3.7.19-285.el6.noarch
selinux-policy-mls-3.7.19-285.el6.noarch
selinux-policy-targeted-3.7.19-285.el6.noarch
shorewall-4.5.4-1.el6.noarch
shorewall6-4.5.4-1.el6.noarch
shorewall6-lite-4.5.4-1.el6.noarch
shorewall-core-4.5.4-1.el6.noarch
shorewall-lite-4.5.4-1.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. get a RHEL-6.7 machine (active targeted policy)
2. run following automated TC:
 * /CoreOS/selinux-policy/Regression/shorewall-and-similar
3. search for SELinux denials

Actual results (enforcing mode):
----
type=SYSCALL msg=audit(12/11/2015 09:25:44.083:253) : arch=x86_64 syscall=socket success=no exit=-13(Permission denied) a0=netlink a1=SOCK_RAW a2=pup a3=0x10 items=0 ppid=15752 pid=15753 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=ipset exe=/usr/sbin/ipset subj=unconfined_u:system_r:shorewall_t:s0 key=(null) 
type=AVC msg=audit(12/11/2015 09:25:44.083:253) : avc:  denied  { create } for  pid=15753 comm=ipset scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=netlink_socket 
----

Expected results:
 * no SELinux denials

Comment 1 Milos Malik 2015-12-11 08:34:18 UTC
Actual results (permissive mode):
----
type=SYSCALL msg=audit(12/11/2015 09:32:45.694:363) : arch=x86_64 syscall=socket success=yes exit=3 a0=netlink a1=SOCK_RAW a2=pup a3=0x10 items=0 ppid=23865 pid=23866 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=ipset exe=/usr/sbin/ipset subj=unconfined_u:system_r:shorewall_t:s0 key=(null) 
type=AVC msg=audit(12/11/2015 09:32:45.694:363) : avc:  denied  { create } for  pid=23866 comm=ipset scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=netlink_socket 
----
type=SOCKADDR msg=audit(12/11/2015 09:32:45.694:364) : saddr=netlink pid:0 
type=SYSCALL msg=audit(12/11/2015 09:32:45.694:364) : arch=x86_64 syscall=bind success=yes exit=0 a0=0x3 a1=0x21a85e4 a2=0xc a3=0x10 items=0 ppid=23865 pid=23866 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=ipset exe=/usr/sbin/ipset subj=unconfined_u:system_r:shorewall_t:s0 key=(null) 
type=AVC msg=audit(12/11/2015 09:32:45.694:364) : avc:  denied  { bind } for  pid=23866 comm=ipset scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=netlink_socket 
----
type=SOCKADDR msg=audit(12/11/2015 09:32:45.694:365) : saddr=netlink pid:23866 
type=SYSCALL msg=audit(12/11/2015 09:32:45.694:365) : arch=x86_64 syscall=getsockname success=yes exit=0 a0=0x3 a1=0x21a85e4 a2=0x7fffaf24f19c a3=0x10 items=0 ppid=23865 pid=23866 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=ipset exe=/usr/sbin/ipset subj=unconfined_u:system_r:shorewall_t:s0 key=(null) 
type=AVC msg=audit(12/11/2015 09:32:45.694:365) : avc:  denied  { getattr } for  pid=23866 comm=ipset scontext=unconfined_u:system_r:shorewall_t:s0 tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=netlink_socket 
----

Comment 6 Milos Malik 2016-01-12 09:52:48 UTC
It's my mistake that the { module_request } denial was not reported sooner. Unfortunately, the domain_kernel_load_modules boolean was enabled on my VMs.

Comment 7 Simon Sekidde 2016-01-12 17:59:22 UTC
(In reply to Milos Malik from comment #6)
> It's my mistake that the { module_request } denial was not reported sooner.
> Unfortunately, the domain_kernel_load_modules boolean was enabled on my VMs.

No problem. Patch sent

commit 0e99bf718ff6c058ffdd07462aed2dabfddd4aa7
Author: Simon Sekidde <ssekidde>
Date:   Tue Jan 12 12:54:27 2016 -0500

    Allow shorewall request kernel load module

Comment 11 errata-xmlrpc 2016-05-10 20:03:46 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.

https://rhn.redhat.com/errata/RHBA-2016-0763.html


Note You need to log in before you can comment on or make changes to this bug.