Bug 878730

+++ 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?