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