SELinux and Shorewall with IPSets

[Stephen Smalley]

On Tue, 2010-06-29 at 00:30 +0100, Mr Dash Four wrote:
> > I think it might be easiest to just label it the same as iptables and
> > then shorewall will transition to iptables_t which already has raw IP
> > socket access as well as other related permissions.  That will be better
> > too in that you don't need to directly allow shorewall or anything else
> > it runs in-domain to have those permissions.
> >
> > semanage fcontext -a -t iptables_exec_t /path/to/ipset
> > restorecon -v /path/to/ipset
> >   
> An elegant solution ... but unfortunately it does NOT work - I am 
> getting the same alerts again.
> 
> The problem (as evident from my initial post on this thread) is that the 
> shorewall init file (normally based in /etc/shorewall/init) executes 
> ipset, which in turn, as you pointed out above, tries to open a raw 
> socket. I am in no way SELinux expert, but I would assume that the 
> security context in which this executes is shorewall and not the one set 
> in ipset.

# sesearch --type -s shorewall_t -t iptables_exec_t
Found 1 semantic te rules:
   type_transition shorewall_t iptables_exec_t : process iptables_t;

The policy defines a transition from shorewall_t to iptables_t upon
executing a binary labeled with iptables_exec_t.  So when shorewall
invokes iptables, it transitions to the right domain.  Labeling ipset in
the same manner would yield the same effect for it.

As a simulation, I did this:
$ cp /usr/bin/id ./myipset
$ chcon -t iptables_exec_t ./myipset
$ setenforce 0
$ runcon system_u:system_r:shorewall_t:s0 /bin/bash -c ./myipset

And it correctly reported that myipset was running in iptables_t.

So I'm curious as to why this isn't working for you.  Did the restorecon
command in fact change the label of the program to iptables_exec_t?  Did
you get the same AVC message as before?

> Anyway, the solution presented by Dominic above works very well, so I 
> may stick with it.

-- 
Stephen Smalley
National Security Agency