Fedora Account System
Red Hat Associate
Red Hat Customer
+++ This bug was initially created as a clone of Bug #873925 +++ Description of problem: 'ipset create' in shorewall init does not create the ipset when initiated by systemd. When run via 'shorewall start' it works. Version-Release number of selected component (if applicable): [root@moses shorewall]# rpm -qa | egrep 'shorewall|ipset' ipset-6.14-1.fc17.x86_64 shorewall-core-4.5.7.1-2.fc17.noarch shorewall-4.5.7.1-2.fc17.noarch ipset-libs-6.14-1.fc17.x86_64 How reproducible: Put in /etc/shorewall/init: id -Z modprobe ip_set ipset create HTTPhacker hash:ip timeout 86400 Steps to Reproduce: 1. [root@moses shorewall]# ipset x HTTPhacker ipset v6.14: The set with the given name does not exist 2. systemctl restart shorewall.service 3. [root@moses shorewall]# ipset list Actual results: no ipset was created Expected results: [root@moses shorewall]# ipset list Name: HTTPhacker Type: hash:ip Revision: 0 Header: family inet hashsize 1024 maxelem 65536 timeout 86400 Size in memory: 16504 References: 0 Members: Additional info (all console commands are root): /var/log/messages snippet from 'systemctl restart shorewall.service': Nov 6 19:59:10 moses shorewall[29995]: Processing /etc/shorewall/init ... Nov 6 19:59:10 moses shorewall[29995]: system_u:system_r:shorewall_t:s0 Nov 6 19:59:10 moses shorewall[29995]: Processing /etc/shorewall/tcclear ... Note the id -Z command output from /etc/shorewall/init. If run via 'shorewall start' from the console: [root@moses shorewall]# ipset x HTTPhacker [root@moses shorewall]# ipset list HTTPhacker ipset v6.14: The set with the given name does not exist [root@moses shorewall]# shorewall restart [root@moses shorewall]# ipset list HTTPhacker Name: HTTPhacker Type: hash:ip Revision: 0 Header: family inet hashsize 1024 maxelem 65536 timeout 86400 Size in memory: 16504 References: 0 Members: console snippet from 'shorewall restart': Processing /etc/shorewall/init ... unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Processing /etc/shorewall/tcclear ... Note the id -Z command output from /etc/shorewall/init. If I replace the 'ipset create' command with 'ipset help' and 'systemctl restart shorewall.service', I DO see the ipset help output in /var/log/messages. There are no selinux messages. I did make this policy to get ipset to run from within shorewall: [root@moses shorewall]# cat /root/config/selinux/local/my_shorewall_ipset.te module my_shorewall_ipset 1.0; require { type shorewall_t; class netlink_socket { bind create getattr }; } #============= shorewall_t ============== allow shorewall_t self:netlink_socket { bind create getattr }; --- Additional comment from Mathieu Bridon on 2012-11-07 10:12:04 HKT --- Can you run "systemctl show shorewall.service" and paste the output here, please? --- Additional comment from Bill Shirley on 2012-11-07 10:27:29 HKT --- Created attachment 639762 [details] Output of "systemctl show shorewall.service" It's several screens full and I don't trust my copy and paste so I'm attaching the output as .txt Bill --- Additional comment from Mathieu Bridon on 2012-11-07 10:34:07 HKT --- So, the interesting lines are the following: Type=oneshot ExecStart={ path=/sbin/shorewall ; argv[]=/sbin/shorewall $OPTIONS start ; ignore_errors=no ; start_time=[Tue, 06 Nov 2012 19:59:09 -0500] ; stop_time=[Tue, 06 Nov 2012 19:59:10 -0500] ; pid=29995 ; code=exited ; status=0 } That means systemd will run "/sbin/shorewall $OPTIONS start", and when the process exits (with status=0), it considers the service is finished properly. Nowhere I see a mention of the /etc/shorewall/init file, so I wonder why you expect it to be read at all. (Please note that I know absolutely nothing about shorewall) --- Additional comment from Bill Shirley on 2012-11-07 10:57:59 HKT --- Shorewall is an iptables firewall. It's configuration consists of many files in /etc/shorewall (zones, hosts, interfaces, etc.) that come together to produce input to the iptables command (an tc command also). The init file is automatically invoked by shorewall: http://shorewall.net/shorewall_extension_scripts.htm I can tell that when shorewall is started by systemd, it does run the ipset command because if I put 'ipset help' in the init I do see the help output in /var/log/messages. But the 'ipset create' does not work and produces no output as to why it didn't work. I'm thinking that if ipset fails for whatever reason I should see some output messages. I just now added 'ipset list' to /etc/shorewall/init and restarted shorewall with systemd: [root@moses local]# ipset x HTTPhacker [root@moses local]# ipset create command_line_ipset hash:ip timeout 1234 [root@moses local]# ipset list Name: command_line_ipset Type: hash:ip Revision: 0 Header: family inet hashsize 1024 maxelem 65536 timeout 1234 Size in memory: 16504 References: 0 Members: and didn't get any output for the 'ipset list' command in /var/log/messages: Nov 6 21:47:41 moses shorewall[5084]: Processing /etc/shorewall/init ... Nov 6 21:47:41 moses shorewall[5084]: system_u:system_r:shorewall_t:s0 Nov 6 21:47:41 moses shorewall[5084]: Processing /etc/shorewall/tcclear ... Now with 'ipset help' in /etc/shorewall/init. I get: Nov 6 21:51:31 moses shorewall[6038]: Processing /etc/shorewall/init ... Nov 6 21:51:31 moses shorewall[6038]: system_u:system_r:shorewall_t:s0 Nov 6 21:51:31 moses shorewall[6038]: ipset v6.14 Nov 6 21:51:31 moses shorewall[6038]: Usage: ipset [options] COMMAND Nov 6 21:51:31 moses shorewall[6038]: Commands: Nov 6 21:51:31 moses shorewall[6038]: create SETNAME TYPENAME [type-specific-options] Nov 6 21:51:31 moses shorewall[6038]: Create a new set Nov 6 21:51:31 moses shorewall[6038]: add SETNAME ENTRY Nov 6 21:51:31 moses shorewall[6038]: Add entry to the named set Nov 6 21:51:31 moses shorewall[6038]: del SETNAME ENTRY Nov 6 21:51:31 moses shorewall[6038]: Delete entry from the named set Nov 6 21:51:31 moses shorewall[6038]: test SETNAME ENTRY Nov 6 21:51:31 moses shorewall[6038]: Test entry in the named set Nov 6 21:51:31 moses shorewall[6038]: destroy [SETNAME] and more. My guess is that ipset is refusing to process commands when shorewall is initiated via systemd but also not producing any output as to why. I noticed that there is a context difference between 'systemctl restart shorewall' and 'shorewall restart' which could be the problem. If this is the case, why is ipset so silent (I'm not using the -q flag)? It should speak up. Bill --- Additional comment from Bill Shirley on 2012-11-07 11:20:55 HKT --- Yes, I was right; it's the context difference: [root@moses local]# setenforce 0 [root@moses testing]# ipset x HTTPhacker [root@moses shorewall]# systemctl restart shorewall.service [root@moses shorewall]# ipset list Name: HTTPhacker Type: hash:ip Revision: 0 Header: family inet hashsize 1024 maxelem 65536 timeout 86400 Size in memory: 16504 References: 0 Members: So the problem is: 1) no output from ipset if the command fails when not using the -q flag 2) no selinux output in either /var/log/audit/audit.log nor /var/log/messages about a denial Bill --- Additional comment from Mathieu Bridon on 2012-11-07 18:44:00 HKT --- @Bill: thanks for tracking that down! From #fedora-selinux: <grift> bochecha thats a bug in selinux-policy not ipset <grift> can you move that bug to selinux-policy? <grift> its creating a netlink socket So I'm moving the bug as suggested. --- Additional comment from Miroslav Grepl on 2012-11-07 20:26:04 HKT --- Added. commit 98b479c50d71adc023f376c5d37c8e40611b1be6 Author: Miroslav Grepl <mgrepl> Date: Wed Nov 7 13:24:53 2012 +0100 Allow shorewall_t to create netlink_socket --- Additional comment from Bill Shirley on 2012-11-09 13:27:00 HKT --- I have already implemented this local policy (see above): allow shorewall_t self:netlink_socket { bind create getattr }; However, the ipset command doesn't work and I don't get any output from neither ipset nor selinux. Is selinux denying this without giving any feedback to ipset nor logging it? --- Additional comment from Daniel Walsh on 2012-11-09 22:09:35 HKT --- Does it work in permissive mode? If yes then try to turn off dontaudit rules. # semodule -DB Try it again, gather the AVC's Turn dontaudit rules back on. # semodule -B --- Additional comment from Bill Shirley on 2012-11-09 22:40:51 HKT --- Created attachment 641572 [details] avcs after 'semodule -DB' then 'systemctl restart shorewall' I did a: grep shorewall /var/log/audit/audit.log There's an 'id' command in there that might help you locate the shorewall init. /etc/shorewall/init: id -Z modprobe ip_set ipset create HTTPhacker hash:ip timeout 86400 #ipset help #ipset -exist create Webaccess hash:ip timeout 3600 #ipset -exist create RefererSpam hash:ip timeout 172800 #ipset -exist create DHCPuser hash:ip timeout 14400 modprobe ifb numifbs=1 ip link set dev ifb0 up #ip link set dev ifb1 up Yes, it creates the ipset list if setenforce 0. Bill --- Additional comment from Miroslav Grepl on 2012-11-09 23:16:29 HKT --- Could you test it with allow shorewall_t self:netlink_socket create_socket_perms; --- Additional comment from Bill Shirley on 2012-11-09 23:37:45 HKT --- I changed my policy: module my_shorewall_ipset 1.0; require { type shorewall_t; class netlink_socket { bind create getattr write read }; } #============= shorewall_t ============== allow shorewall_t self:netlink_socket { bind create getattr write read }; It now works: [root@moses testing]# ipset x HTTPhacker [root@moses testing]# setenforce 1 [root@moses testing]# systemctl restart shorewall.service [root@moses testing]# ipset list Name: HTTPhacker Type: hash:ip Revision: 0 Header: family inet hashsize 1024 maxelem 65536 timeout 86400 Size in memory: 16504 References: 0 Members: Bill --- Additional comment from Bill Shirley on 2012-11-09 23:42:43 HKT --- Just another thought, shouldn't ipset know that the action was denied? Wouldn't that be in the return code? An ipset 'permission denied' message would be nice. Bill --- Additional comment from Daniel Walsh on 2012-11-13 19:34:26 HKT --- Open another bugzilla with ipset. --- Additional comment from Bill Shirley on 2012-11-13 20:32:49 HKT --- I just changed the component back to ipset. There's a lot of info already here. Bill --- Additional comment from Mathieu Bridon on 2012-11-13 23:08:00 HKT --- So, I think I will just open an upstream bug on this one, because there's really not a lot I can do about it unfortunately. Bill, do you have an account in the ipset upstream bug tracker: http://bugzilla.netfilter.org If not, I can open the bug there myself. --- Additional comment from Bill Shirley on 2012-11-14 10:37:03 HKT --- No, I don't have an account. Sorry. Bill --- Additional comment from Mathieu Bridon on 2012-11-19 12:23:21 HKT --- Just opened the upstream bug report asking for ipset oto let the user know it couldn't perform when being denied by SELinux. Hopefully, upstream will fix the issue soon, but there's not much I can do about it now. However, that's really a second bug, so now that it's reported upstream, let's concentrate on solving the SELinux denial here. Miroslav, Daniel, did you get to commit the new policy which allows this?
Bill, upstream asked me to try to run ipset through strace to see what happens: http://bugzilla.netfilter.org/show_bug.cgi?id=802#c1 I don't have a Fedora 17 handy, could you try it? It should be as simple as putting the following line in your /etc/shorewall/init: strace -s 2048 -o /tmp/ipset.strace ipset create HTTPhacker hash:ip timeout 86400 Then attach the resulting /tmp/ipset.strace file here.
It has been also added to F17. commit 98b479c50d71adc023f376c5d37c8e40611b1be6 Author: Miroslav Grepl <mgrepl> Date: Wed Nov 7 13:24:53 2012 +0100 Allow shorewall_t to create netlink_socket
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.