Red Hat Bugzilla – Bug 1290705
SELinux prevents ipset from creating a netlink socket
Last modified: 2016-05-10 16:03:46 EDT
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
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 ----
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.
(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@redhat.com> Date: Tue Jan 12 12:54:27 2016 -0500 Allow shorewall request kernel load module
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