On Thu, Dec 23, 2010 at 05:03:56PM +0100, Thomas Woerner wrote:
Hello,
as discussed some time ago, I worked on the proof of concept
implementation of firewalld. FirewallD is a service daemon with a D-BUS
interface that provides a dynamic managed firewall.
For more information on firewalld, please have a look at:
https://fedoraproject.org/wiki/FirewallD/
About this version:
This is mostly the proof of concept implementation with some changes and
is feature complete for F-15 as a firewalld preview version. It will not
be enabled per default and will also not get installed per default. The
system-config-firewall with static firewall model will still be the
default firewall solution for Fedora 15.
What this firewalld version can do:
- It supports most of the firewall features system-config-firewall had,
but there are three limitations:
1) custom firewall rule files (iptables save format) are not
supported and most likely will never be, but there is support for
custom rules (limited functionality).
2) sysctl changes for ip_forward are not done, yet.
3) There are no permanent firewall settings, this means that all
settings are lost after a service restart or reboot. Permanent
firewall settings will be added later on.
Lack of persistence across reboots isn't a problem for libvirt needs,
but we would expect even non-persistent rules to survive a restart of
the firewalld process. Currently everything is torn down when firewalld
stops, so if you need todo a 'service firewalld restart' in an RPM
postscript during RPM upgrades, then you will interrupt traffic to/from
guests, or temporarily open security holes in the network filtering of
guests. Thus, the teardown and setup of firewall rules must be decoupled
from the firewalld process startup/shutdown lifecycle, to allow restarts
of firewalld without causing a security weakness/service interruption.
- There is an rule and chain interface for libvirt, but the
PolicyKit
policy is not in place, yet.
Looking at the dbus API this appears to let me add/remove/query
rules in the INPUT_libvirt, OUTPUT_libvirt FORWARD_libvirt
chains, but AFAICT it doesn't yet provide any way to create
additional chains.
eg, the setup we need for libvirt has chains linked quite a few
levels deep.
Chain: PREROUTING_libvirt
-i vnet0 -j libvirt-I-vnet0
-i vnet1 -j libvirt-I-vnet1
-i vnet2 -j libvirt-I-vnet2
...
Chain: libvirt-I-vnet0
-p IPv4 -j I-vnet0-ipv4
-p ARP -j I-vnet0-arp
-p 0x8035 -j I-vnet0-rarp
-p 0x835 -j ACCEPT
-j DROP
Chain: I-vnet0-ipv4
....
Chain: I-vnet0-arp
....
Chain: I-vnet0-rarp
....
And so on for vnet1, vnet2, and more
Also, the naming of the extra chains needs to be completely controlled
by libvirt with no extra prefix added by firewalld. This is because
the iptables kernel chain name length limit is very short and thus we
need to use every byte available :-(
Regards,
Daniel