firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)

Daniel P. Berrange berrange at
Wed Jan 5 13:29:51 UTC 2011

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:
> 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 :-(


More information about the devel mailing list