On Mon, 2011-08-01 at 09:40 -0700, Andrew Silverman wrote: > 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.
Thanks, Andy! > > 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 failure doesn't require the use of /etc/rc.d/rc.local; it will happen with a standard Shorewall installation. > The exact > steps were pretty much called out here: > http://wiki.centos.org/HowTos/SELinux. This article is well worth a read. > > > 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 That should be /var/log/audit/audit.log. > > 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 Ditto. > > 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. > > > Thanks Tom for the pointer in the right direction... > You are most welcome, Andy. And thanks again, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
