Ok, so here's the detailed version of the fix for getting shorewall6 running
at boot time on an SELinux machine. (This is probably equally valid for
shorewall IPv4 too, but I'm using it only for IPv6 at the moment...) This
is on a vanilla CentOS 6.0 setup.
The problem (restated):
- My IPv6 config requires running a few lines to set up the Hurricane
Electric 6in4 tunnel after NetworkManager brings up the interfaces, pretty
much straight out of the HE "example" configs, e.g. (addresses obscured for
obvious reasons)
ip tunnel add he-ipv6 mode sit remote xx.xx.xx.xx local xx.xx.xx.xx ttl
255
ip addr add 2001:xxx:a:xxx::2/64 dev he-ipv6
ip addr add 2001:xxx:b:5fd::1/64 dev eth1
ip route add ::/0 dev he-ipv6
These lines were added to /etc/rc.d/rc.local so that they would be run after
all the other init scripts are completed. This gets the tunnel going and
assigns the proper static addresses and routes to the LAN side physical
interface and to the tunnel pseudo-interface.
Now the problem is that after those lines, I want to do:
/sbin/shorewall6 start (to start the firewall)
radvd (to start the router advertisement daemon.)
Looking in the boot logs, I could see that shorewall6 was failing to start
after trying to read the /etc/shorewall6/params file, and then radvd fails
to start because it sees IPv6 forwarding has not been enabled. But running
them both from a su prompt worked fine. I had a suspicion that this was
some sort of permissions problem as a result, but I'm really barely even a
linux noob let alone guru. Tom was kind enough to repro this and identify
it as an SELinux permissions problem - so I ran with the ball and did some
digging and experimentation and in an hour or two had it solved. The exact
steps were pretty much called out here:
http://wiki.centos.org/HowTos/SELinux. This article is well worth a read.
The easiest solution would of course be just to disable SELinux security
altogether, which can be done by a trivial edit to the /etc/selinux/config
file, SELINUX=DISABLED. But this defeats the purpose of ensuring that the
system is better protected from a variety of security weaknesses. Instead,
what you do is change that line to SELINUX=PERMISSIVE and then reboot.
SELinux will then allow things that would ordinarily be denied to succeed,
but logs are written that can be further analyzed in a very simple fashion.
- Install the setroubleshoot package if it's not on your system already.
Then reboot so that the proper logs are written out.
- Run the GUI tool or "sealert -a /var/log/audit/audit.log >
/path/to/mylogfile.txt" as root.
This parses the /var/log/audit/audit.log file into human readable form and
shows you what's failing.
In this particular case, two problems turn up:
1) shorewall6 is not permitted to access the files in the /etc paths when
running from your init scripts.
2) radvd is making some system call that isn't expected, from the boot logs
I think it was trying to access radvd.pid and failing.
Luckily the process of creating new security policy to allow the specific
failures is fairly automated via the audit2allow tool and the semodule tool.
First:
grep shorewall /var/audit/audit.log | audit2allow -m shorewall6 >
shorewall6.te
You can view the resulting shorewall6.te file to see what changes are
required to the existing security policy and decide whether they're OK. In
this case they're not really controversial, it's just expected file access.
To then create a compiled security policy that can be installed to the
system re-run it with the capital M option instead and no output
redirection, like this:
grep shorewall /var/audit/audit.log | audit2allow -M shorewall6
This creates a shorewall6.pp file which is then installed to the system with
the command:
semodule -i shorewall6
This command takes longer than expected but if it returns without errors,
the shorewall problem is now fixed.
You can then redo this process, grepping for radvd instead. Because radvd
seems to install its own SELinux policies when the package is installed (so
why isn't this error found?) I created an "radvd2" policy instead, because
when I called the policy package "radvd" I was getting some weird errors on
the final step where it tries to install the policy, possibly because a
policy by that same name already exists and it was having trouble merging
the two or something.
After installing the two new security policies, make sure you re-edit the
/etc/selinux/config file to turn enforcing mode back on, then reboot again.
If all is well, you should be able to do "shorewall6 status" after boot and
see that it's now running, and similarly "ps -e | grep radvd" should show
that radvd is now running as well. Problem solved!
Thanks Tom for the pointer in the right direction...
Andy
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
