Bug 873925

Can you run "systemctl show shorewall.service" and paste the output here, please?

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

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)

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

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

@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.

Added.

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

    Allow shorewall_t to create netlink_socket

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?

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

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

Could you test it with

allow shorewall_t self:netlink_socket create_socket_perms;

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

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

Open another bugzilla with ipset.

I just changed the component back to ipset.  There's a lot of info already here.

Bill

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.

No, I don't have an account.  Sorry.

Bill

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?

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.

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

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).

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.