Bug 873925 - ipset create in /etc/shorewall/init does not create the ipset when initiated by systemd
Summary: ipset create in /etc/shorewall/init does not create the ipset when initiated ...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 17
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-07 01:18 UTC by Bill Shirley
Modified: 2012-12-20 16:09 UTC (History)
4 users (show)

(edit)
Clone Of:
: 878730 (view as bug list)
(edit)
Last Closed: 2012-12-20 16:09:42 UTC


Attachments (Terms of Use)
Output of "systemctl show shorewall.service" (3.31 KB, text/plain)
2012-11-07 02:27 UTC, Bill Shirley
no flags Details
avcs after 'semodule -DB' then 'systemctl restart shorewall' (237.43 KB, text/plain)
2012-11-09 14:40 UTC, Bill Shirley
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Netfilter 802 None None None Never

Description Bill Shirley 2012-11-07 01:18:29 UTC
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 };

Comment 1 Mathieu Bridon 2012-11-07 02:12:04 UTC
Can you run "systemctl show shorewall.service" and paste the output here, please?

Comment 2 Bill Shirley 2012-11-07 02:27:29 UTC
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

Comment 3 Mathieu Bridon 2012-11-07 02:34:07 UTC
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)

Comment 4 Bill Shirley 2012-11-07 02:57:59 UTC
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

Comment 5 Bill Shirley 2012-11-07 03:20:55 UTC
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

Comment 6 Mathieu Bridon 2012-11-07 10:44:00 UTC
@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.

Comment 7 Miroslav Grepl 2012-11-07 12:26:04 UTC
Added.

commit 98b479c50d71adc023f376c5d37c8e40611b1be6
Author: Miroslav Grepl <mgrepl@redhat.com>
Date:   Wed Nov 7 13:24:53 2012 +0100

    Allow shorewall_t to create netlink_socket

Comment 8 Bill Shirley 2012-11-09 05:27:00 UTC
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?

Comment 9 Daniel Walsh 2012-11-09 14:09:35 UTC
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

Comment 10 Bill Shirley 2012-11-09 14:40:51 UTC
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

Comment 11 Miroslav Grepl 2012-11-09 15:16:29 UTC
Could you test it with

allow shorewall_t self:netlink_socket create_socket_perms;

Comment 12 Bill Shirley 2012-11-09 15:37:45 UTC
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

Comment 13 Bill Shirley 2012-11-09 15:42:43 UTC
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

Comment 14 Daniel Walsh 2012-11-13 11:34:26 UTC
Open another bugzilla with ipset.

Comment 15 Bill Shirley 2012-11-13 12:32:49 UTC
I just changed the component back to ipset.  There's a lot of info already here.

Bill

Comment 16 Mathieu Bridon 2012-11-13 15:08:00 UTC
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.

Comment 17 Bill Shirley 2012-11-14 02:37:03 UTC
No, I don't have an account.  Sorry.

Bill

Comment 18 Mathieu Bridon 2012-11-19 04:23:21 UTC
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?

Comment 19 Mathieu Bridon 2012-11-21 04:58:30 UTC
Reassigning this bug to selinux-policy, so we can finish tracking that issue here.

I cloned the bug to 878730 for the related issue where ipset doesn't output any message about being denied by SELinux.

Comment 20 Fedora Update System 2012-11-21 11:52:52 UTC
selinux-policy-3.10.0-161.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-161.fc17

Comment 21 Fedora Update System 2012-11-22 03:54:44 UTC
Package selinux-policy-3.10.0-161.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-161.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-18787/selinux-policy-3.10.0-161.fc17
then log in and leave karma (feedback).

Comment 22 Fedora Update System 2012-12-20 16:09:44 UTC
selinux-policy-3.10.0-161.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.


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