Bug 227011

Created attachment 147236 [details]
iptables-init-script-separate-rules-config.patch

See what went into libvirt:

   http://www.redhat.com/archives/libvir-list/2007-February/msg00056.html

We can now build libvirt with:

  $> ./configure --with-iptables-prefix=RH-libvirt- 
                 --with-iptables-dir=/etc/init.d/iptables.d

in order to integrate with the iptables init script patch

Oh, the default /etc/sysconfig/iptables would need to contain:

IPTABLES_FILTER_INPUT_CHAINS="RH-libvirt-INPUT RH-Firewall-1-INPUT"
IPTABLES_FILTER_FORWARD_CHAINS="RH-libvirt-FORWARD RH-Firewall-1-FORWARD"
IPTABLES_NAT_PREROUTING_CHAINS="RH-libvirt-PREROUTING"
IPTABLES_NAT_POSTROUTING_CHAINS="RH-libvirt-POSTROUTING"

Just to re-iterate some points on this:

  - only chains listed in /etc/sysconfig/iptables are added from iptables.d

  - we need a --ignore parameter to iptables-save so that "service iptables
    save" doesn't save any of the chains that were loaded from iptables.d

  - we'll need to change s-c-fw to save its rules to iptables.d and delete
    /etc/sysconfig/iptables.

  - "service iptables save" now saves to /etc/sysconfig/iptables-saved

  - the initscript *either* loads /etc/sysconfig/iptables, if it exists,
    or first the chains from iptables.d and then the contents of
    /etc/sysconfig/iptables-saved.  This provides us with a sane migration
    path.

  - the order in which chains from iptables.d are loaded is specified in 
    iptables-config

  - all this is intended to address the problem of that all libvirt can do
    right now is insert (i.e. -I) it's rules to the INPUT etc. chains and
    those rules get summarily wiped out by "service iptables reload" and
    saved by "service iptables save"

  - one bug I see in the patch is that load_iptables() should load 
    /etc/sysconfig/iptables-saved"

How can the user configure, what each each virtual network can access locally
and in other networks (even external) and if the network is accessible from
other networks or from extern?

system-config-firewall in devel provides the ability to load custom rules.
Please have a look at "lokkit --help". You can add a file with your rules by
using "lokkit --custom-rules=ipv4:filter:/etc/sysconfig/my_rules_file".
lokkit also got an new option "--update" which regenerates the firewall rules
for ipv4 and ipv6. Use this if you are udating custom rules and want that the
changes are persistent.
The enhancements in lokkit does not require a change in the firewall handling
for iptables; it does not know anything about the includes. This solution is
transparent in use especially for updaters.

Please have a look at this solution and report problems if you have any.
Thanks

Assigning to system-config-firewall.

twoerner: thanks, --custom-rules works just fine for us. See the libvirt patch
I've just posted:

  http://www.redhat.com/archives/libvir-list/2008-January/msg00025.html

The approach taken here is not sufficient. I had edited /etc/sysconfig/iptables
manually, and an update of libvirt clobbered those manual changes. The change I
made was adding a rule to forward packets across a bridged device (to make DHCP
work across the bridge) The change was made before lokkit (or
system-config-firewall) was ever used.

lokkit should not clobber /etc/sysconfig/iptables if the file has been edited
manually. Barring that, it needs to back the original iptables file up.

Generally, the approach of turning what used to be the authoritative config file
(/etc/sysconfig/iptables) into a generated file is fatally flawed exactly
because it clobbers manual edits.

lokkit --custom-rules behavior is fine - if a user explicitly chooses to  modify
your firewall configuration, then overwriting an existing
/etc/sysconfig/iptables is expected behaviour.

However, lokkit --custom-rules is not an appropriate integration point for libvirt.

Merely by *installing the libvirt package* a default virtual network is set up
which involves adding rules to allow traffic to be forwarded across a bridge and
NAT-ed to external physical networks.

It is not acceptable that installing libvirt should overwrite a users custom
iptables configuration.

This goes back to the original intention of this bug and the patch in comment #1.

What libvirt needs is a way for it to have its rules loaded by the iptables
initscript irrespective of whether the user has manually configured iptables or
used system-config-firewall

See also bug #449996

See bug #449996#c4

(In reply to comment #11)
> See bug #449996#c4

quoting:

    Use "lokkit --disabled" and lokkit will not touch the firewall 
    configuration files anymore. This is and was the way lokkit behaves 
    since some years.

So ... we should recommend to users that if they have custom rules in
/etc/sysconfig/iptables, they should either

 a) Add those custom rules to lokkit --with-custom-rules or

 b) Disable lokkit with lokkit --disabled, which will mean that libvirt's
    rules will be clobbered if they do "service iptables restart"

and they should choose which they want to do *before* installing libvirt.


This clearly is not a workable solution - users cannot know to make this
decision before installing libvirt and if they don't make this decision, users
with a working setup will find their setup broken by the mere act of installing
(or updating to a more recent) libvirt


lokkit is a tool for users to modify the firewall config, and libvirt should not
be clobbering user's configuration - I'm really failing to see how lokkit can be
made to be a suitable integration point for system software like libvirt

Hence the /etc/sysconfig/iptables.d idea so that libvirt can integrate in a way
that doesn't clobber user configuration

Being able to just drop a file into /etc/sysconfig/iptables.d would also allow
us to have a more tightly controlled SELinux policy - libvirtd would merely need
to be able to drop files into that location, and not require ability to execute
lokkit with the extra privileges this entails.

Comment #12:
No they should choose before making custom /etc/sysconfig/ip*tables files.

The order or rules is very important, how do you want to make sure that your
custom rules or the ones from libvirtd or SElinux are placed into the right
position, especially if a user is adding files with own rules, too? 

"service iptables save" would not be usable with this anymore. This mechanism is
used in our training courses and would also mean a change in behavior for EL.

Comment #13: What will be more tight with /etc/sysconfig/iptables.d than it is
with current custom-rules option of lokkit? libvirt would need the ability to
restart the iptables and ip6tables services, so where is the difference?

This is the email I have sent to David about his question of parsing and
modifying ip*tables configurations:

---
I thought a lot about that in the past, but there are some problems with using
user-customized configurations:

1) There are iptables and ip6tables, the options for them are not the same,
there are even some major differences, like missing modules, other module
options, other arguments etc. Also there is no NAT for netfilter-v6. You have to
be able to modify both accordingly.

2) You could configure ip*tables in two different ways:
- Default policy: accept, reject/drop not wanted
- Default policy: deny, open up wanted
Both are in use out there.

3) The configuration system needs to understand every possible module
configuration and combination of modules and options to insert the changes into
the proper line or even worse into the proper chain. Please remember that you
can create your own chains, that could branch to other chains or return back.

4) netfilter and netfilter-v6 are moving targets. With every new kernel version
there are new modules and sometimes also removed or renamed modules or options
and also behaviour changes. Having a parser for iptables, which is able to parse
and also generate a valid configuration for every netfilter version is hard to
do. Having a parser for ip*tables will be lots of work to have it in sync with
netfilter in the various kernel versions.

5) Modifying the firewall configuration in a way that it breaks or that it is
opening the firewall up by mistake will be a major problem. This could happen,
if you put a rule into the wrong line. iptables-restore aborts on error.
Ignoring errors if you apply a new configuration could also result in a useless
firewall, either opened up or closed.

6) Limiting your desired configuration system to only a limited part of the
netfilter capabilities (modules, options, arguments, ..) is not an option.
Therefore the capabilities of this configuration system has to be identical to
the netfilter and netfilter-v6 capabilities in the kernel. In every kernel
version we ship for a release or even for all releases. Please also think of
updates: we often push a new kernel (with newer netfilter) into all current
Fedora releases.


I have had a parser, that was able to load nearly every netfilter configuration
some years ago, but the problem was that I had to build a netfilter-a'like
system to be able to get a system which could understand the configuration. Now,
this is a no-go in my opinion, because netfilter is moving too fast.

I thought about not building the firewall configuration files at all anymore.
This will be the best solution, I think. If the files are there, they are used
as is and the firewall is user-customized. If the files are missing (both of
them) then the firewall is generated dynamically. The problem with this is that
we are using the "service iptables save" command in our RH courses and this will
break it. This is also a change in behavior, which will be hard for EL.
---

(In reply to comment #14)
> Comment #12:
> No they should choose before making custom /etc/sysconfig/ip*tables files.

That event is in the past. If people have a working setup involving custom
/etc/sysconfig/iptables, then we shouldn't break it.

> The order or rules is very important, how do you want to make sure that your
> custom rules or the ones from libvirtd or SElinux are placed into the right
> position, especially if a user is adding files with own rules, too? 

That is an issue irrespective of whether we have /etc/sysconfig/iptables.d or
lokkit --with-custom-rules

The way I look at it is that the default policy is REJECT and most everyone is
adding ACCEPT rules, so conflicts don't matter. That's a huge generalization,
but anyone adding rules would need to be mindful of the possibility of
conflicts. It's a shared resource with multiple users, I don't see how you can
avoid the issue.

> "service iptables save" would not be usable with this anymore.

Why not?

Do you mean that if you do "service iptables save" that all the rules form
/etc/sysconfig/iptables.d would be saved into /etc/sysconfig/iptables and you'd
have two copies of the rules? That's the issue I want to fix by adding
iptables-save --ignore

Or are you referring to something else ...?

I'm confident issues like this could be worked out. The proposed patch is merely
a proof-of-concept. If you agreed in principle that /etc/sysconfig/iptables.d
might be acceptable, we could work to resolve those issues.

> Comment #13: What will be more tight with /etc/sysconfig/iptables.d than it is
> with current custom-rules option of lokkit? 

It would not involve libvirt overwriting a users custom rules in
/etc/sysconfig/iptables

> libvirt would need the ability to
> restart the iptables and ip6tables services, so where is the difference?

No, libvirt would not need the ability to restart iptables. It adds the rules
itself *and* writes out a file to /etc/sysconfig/iptables.d

(In reply to comment #15)
> This is the email I have sent to David about his question of parsing and
> modifying ip*tables configurations:

Which question? It sounds like this might have been related to augeas? I'm not
sure this is related to the question of how libvirt should integrate correctly
with iptables

(Are you conflating two issues just because the same people are invovled or ...?
Am I just missing some context here?)

(In reply to comment #16)
> (In reply to comment #14)
> > The order or rules is very important, how do you want to make sure that your
> > custom rules or the ones from libvirtd or SElinux are placed into the right
> > position, especially if a user is adding files with own rules, too? 
> 
> That is an issue irrespective of whether we have /etc/sysconfig/iptables.d or
> lokkit --with-custom-rules
> 
> The way I look at it is that the default policy is REJECT and most everyone is
> adding ACCEPT rules, so conflicts don't matter. That's a huge generalization,
> but anyone adding rules would need to be mindful of the possibility of
> conflicts. It's a shared resource with multiple users, I don't see how you can
> avoid the issue.

Or to put it another way - libvirt needs to add these rules to offer the
functionality of Virtual Networks.

Currently we do add the rules, without calling out to lokkit, so there is
possibility of conflict between rules anyway.

libvirt using /etc/sysconfig/iptables.d would not increase the likelihood of a
conflict between rules.

If we conclude that the possibility of conflict means that we shouldn't be
adding rules, then we also must conclude that we cannot offer this functionality.

Two things first: 
1) We do not have one firewall, we have two: iptables for IPv4 and ip6tables for
IPv6. Please keep in mind, that we have to take care of both. 
2) lokkit is an abstraction layer for both firewalls. It takes care of adding
services etc. and there are no changes needed to iptables applications or the
behaviour of the init script at all.

Comment #16:
> That is an issue irrespective of whether we have /etc/sysconfig/iptables.d or
> lokkit --with-custom-rules
Correct, but lokkit is adding custom-rules at the end after the normal
configuration is done. Surely you could force to prepend rules with iptables
calls, but then you should know, what you do.

> The way I look at it is that the default policy is REJECT and most everyone is
> adding ACCEPT rules, so conflicts don't matter. That's a huge generalization,
> but anyone adding rules would need to be mindful of the possibility of
> conflicts. It's a shared resource with multiple users, I don't see how you can
> avoid the issue.
This is wrong. The default policy is accept for us, ports/rules to be opened up
are marked to be accepted, the remaining things are rejected with a special
reject type.

The order does matter. Please have a look at this configuration example:
  -A INPUT -t tcp -m tcp --dport 22 -s 10.32.0.0/24 -j DROP
  -A INPUT -t tcp -m tcp --dport 22 -j ACCEPT
First match first serve.

Which rules do you want to ignore with "iptables-save --ignore"? How do you want
to get the rules back into the right ordering when you apply the firewall again? 
In the example above the user inserted the rule "-A INPUT -t tcp -m tcp --dport
22 -s 10.32.0.0/24 -j DROP" by hand. It is not part of the normal configuration.
Then he uses "service iptables save". Where do you want to save this rule? Where
do you want to add it again? If you add it after the accept line, it is
completely useless.

Another thing that the user can do is to remove an existing rule from your
preconfigured configuration from /etc/sysconfig/ip*tables.d. If he uses the save
command, what would you save then?

> It would not involve libvirt overwriting a users custom rules in
> /etc/sysconfig/iptables
and
> No, libvirt would not need the ability to restart iptables. It adds the rules
> itself *and* writes out a file to /etc/sysconfig/iptables.d
I do not see, where the difference is: "It adds the rules
itself *and* writes out a file to /etc/sysconfig/iptables.d" and it adds the
rules itself and adds a custom file with using "lokkit --nostart
--custom-rules=XYZ.file". This is absolutely identical.

> If you agreed in principle that /etc/sysconfig/iptables.d might be acceptable, 
> we could work to resolve those issues.
Indeed, it would be nice to have a system like this, but how do you want to
resolve the problems? I have had a look at many configuration tools for
netfilter and netfilter-v6, and all limited the functionality in this area,
because ordering is the most important thing and we need to be able to save a
current configuration regardless if it matches preconfigured files or not.

Comment #17: I put it in the bugzilla, because there are some explanations in
the text. which I do not want to write again. Please also have a look at the
last section of comment #15.

Comment #18:
> If we conclude that the possibility of conflict means that we shouldn't be
> adding rules, then we also must conclude that we cannot offer this 
> functionality.
Correct, this is the problem with custom rules.

This is more than just a libvirt problem.  NetworkManager's new connection sharing feature clobbers the libvirt rules.   See bug #458625.

Is there any way forward on this?  As both of the 'mess with iptables' contenders are actually after a very simple NAT networking setup, perhaps that could be accommodated more easily with a shared set of rules (that would step on fewer other toes?)

Thinking about the 'NAT networks' rule idea, could we have a generic rule included in the default ruleset, that jumps to a 'consdier for NAT chain'.

Then programs such as libvirt and NetworkManager can simply add and remove rules that permit access to another 'NAT these packets' chain?  (being empty, would be harmless until needed)

That would seem to allow easy, deterministic modification of the NAT table, including for more traditional NAT setups (not using NetworkManger).

Thoughts?

*** Bug 519439 has been marked as a duplicate of this bug. ***

*** Bug 546064 has been marked as a duplicate of this bug. ***

*** Bug 539744 has been marked as a duplicate of this bug. ***

I still like the idea of having a directory we can drop modular set of rules into.

We manage our systems centrally and push out configurations from a central repository.

Being able to push out say an /etc/sysconfig/iptables.d/kvm, /etc/sysconfig/iptables.d/ldapd, /etc/sysconfig/iptables.d/snmp etc..separately as needed depending on the functions that server is performing would be wonderfully intuitive for those of us that manage our systems in this way.

I would say that MOST systems are running as deny all, and opening ports/traffic as needed, ala using the firewall like tcpwrappers.

FWIW, I'm a large user of the shorewall firewall [1] and I thought I'd mention that it's always good when things that play with iptables, play nicely with shorewall too.

My use case is that I use shorewall instead of the "iptables service" to manage iptables, and as such, when libvirt adds things to iptables, shorewall doesn't know they're added... Shorewall is quite "big" with servers, and this will be more relevant as more and more servers use kvm+libvirt, etc...

HTH

[1] http://www.shorewall.net/

Is this now FirewallD?

https://fedoraproject.org/wiki/FirewallD/

firewalld provides a dynamic firewall with a D-BUS interface. system-config-firewall on the other hand provides a static firewall.

With the D-BUS interface of firewalld it is possible to add firewall rules using the daemon. This way firewalld knows about the rules and can handle them for example in a reload or restart case. firewalld is also able to add and remove rules without the need to restart the whole firewall. This is very good for established connections.

For more information, please have a look at https://fedoraproject.org/wiki/FirewallD/

firewalld will not replace system-config-firewall, but it will be the default firewall solution in Fedora as soon as it is ready and stable. system-config-firewall will still be available for static firewall solutions, but it will be optional.

While firewalld is a nice solution, AFAICT, the current impl has some limitations that prevent us using it, eg

http://lists.fedoraproject.org/pipermail/devel/2011-January/147613.html

This problem has been driving us potty for years - is there no way to integrate this properly?

My main gripe is that libvirtd appears to INSERTS rules into the FORWARD chain:

# iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -d 192.168.100.0/24 -i eth0 -o virbr1 -j ACCEPT
-A FORWARD -s 192.168.100.0/24 -i virbr1 -o eth0 -j ACCEPT
-A FORWARD -i virbr1 -o virbr1 -j ACCEPT
-A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable

and then icmp-port-unreachable rules clobber my following rules...

-A FORWARD -s 0.0.0.0/32 -d 224.0.0.1/32 -i virbr1 -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.0.30/32 -d 192.168.0.7/32 -i tun+ -o eth0 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A FORWARD -s 192.168.0.7/32 -d 192.168.100.2/32 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A FORWARD -s 192.168.0.30/32 -d 192.168.100.2/32 -i tun+ -o virbr1 -p tcp -m tcp --dport 5280 -j ACCEPT
-A FORWARD -s 192.168.100.2/32 -d 192.168.0.30/32 -i virbr1 -o tun+ -p tcp -m tcp --sport 5280 -j ACCEPT
etc...

I would prefer that libvirtd doesn't meddle with iptables and let me manage it, although it would be nice if it just worked automatically as VMs are created/destroyed.

It would alleviate the problem a bit if 
FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
were appended to FORWARD instead of inserted.

I use /etc/init.d/iptables save for persistency. If libvirtd is active, then its rules get saved too, and then duplicated rules are added again when libvirtd boots. It needs to be more intelligent:

iptables is queryable using -S through grep - if the rule exists, then don't add the rule again. We can even work out how many times to remove a duplicated rule using tail -n +2:
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
...

# remove all but 1 duplicated rule:
IFS=$'\n'; for i in `iptables -t mangle -S POSTROUTING | grep ' -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill' | tail -n +2 | cut -b 4-`; do echo /sbin/iptables -t mangle -D $i > tmp.sh; bash tmp.sh; done; rm -f tmp.sh;

`/sbin/iptables -t mangle -D $i` should work but it doesn't - iptables thinks the whole command line is a too-long chain name and barfs, so have to work around it by squirting the commands to a shell script then executing that instead. :(

Append REJECT rules to the end of an existing FORWARD chain.
libvirtd could just advise on what rules to use, instead of blindly modifying.
Users should be able to manage iptables themselves instead of hacking hacks to undo the damage.

Here's a fairly rough script I wrote to remove duplicate rules, and move icmp-port-unreachable rules to the end of the forward chain.
It's not perfect, but may help someone as a starting point.
Chances are that anyone using a FORWARD rule would already have this rule
FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
as the first one. This would forward all established connections anyway, so making libvirtd's per VM forward rules redundant.

#!/bin/bash

[[ -e tmp.sh ]] && rm -f tmp.sh;
[[ -e foundrules.txt ]] && rm -f foundrules.txt; touch foundrules.txt;

IFS=$'\n';
for i in `iptables -t mangle -S POSTROUTING | grep ' -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill' | tail -n +2 | cut -b 4-`; do
    echo /sbin/iptables -t mangle -D $i >> tmp.sh;
done;
[[ -e tmp.sh ]] && ( bash tmp.sh; rm -f tmp.sh; )

for rule in $(cat <<-!
FORWARD -d .* -o virbr.* -m state --state RELATED,ESTABLISHED -j ACCEPT
FORWARD -s .* -i virbr.* -j ACCEPT
FORWARD -i virbr.* -o virbr.* -j ACCEPT
!
); do
    `iptables -S FORWARD | egrep "$rule" | cut -b 4- | sort -m -u >> foundrules.txt`;
done;

for rule in $(cat foundrules.txt); do
    echo rule $rule;
    for i in `iptables -S FORWARD | grep "$rule" | tail -n +2 | cut -b 4-`; do
        echo /sbin/iptables -t filter -D $i >> tmp.sh;
    done;
done;

[[ -e foundrules.txt ]] && rm -f foundrules.txt
[[ -e tmp.sh ]] && ( bash tmp.sh; rm -f tmp.sh )

for i in `iptables -S FORWARD | grep 'FORWARD -. virbr. -j REJECT --reject-with icmp-port-unreachable' | cut -b 4-`; do
    echo /sbin/iptables -t filter -D $i >> tmp.sh;
    echo /sbin/iptables -t filter -A $i >> tosort.sh;
done;
[[ -e tmp.sh ]] && ( bash tmp.sh; rm -f tmp.sh; )
[[ -e tosort.sh ]] && ( cat tosort.sh | sort -u > tmp.sh; rm -f tosort.sh; )
[[ -e tmp.sh ]] && ( bash tmp.sh; rm -f tmp.sh; )

for rule in $(cat <<-!
INPUT -i virbr. -p udp -m udp --dport 53 -j ACCEPT
INPUT -i virbr. -p tcp -m tcp --dport 53 -j ACCEPT
INPUT -i virbr. -p udp -m udp --dport 67 -j ACCEPT
INPUT -i virbr. -p tcp -m tcp --dport 67 -j ACCEPT
!
); do
    for i in `iptables -S INPUT | grep " $rule" | cut -b 4-`; do
        echo /sbin/iptables -t filter -D $i >> tmp.sh;
        echo /sbin/iptables -t filter -I $i >> tosort.sh;
    done;
done;
[[ -e tmp.sh ]] && ( bash tmp.sh; rm -f tmp.sh; )
[[ -e tosort.sh ]] && ( cat tosort.sh | sort -m -u > tmp.sh; rm -f tosort.sh; )
[[ -e tmp.sh ]] && ( bash tmp.sh; rm -f tmp.sh; )

As per See Also private Bug 725094, this functionality is available in lokkit. Adding the closing comment from that bug, for public visibility.

> Lokkit as a frontend tool for our iptables configuration already provides
> such a mechanism, see lokkit --help:
> 
>   --custom-rules=[<type>:][<table>:]<filename>
>                         Specify a custom rules file for inclusion in the
>                         firewall, after the default rules. Default protocol
>                         type: ipv4, default table: filter. (Example:
>                         ipv4:filter:/etc/sysconfig/ipv4_filter_addon)
> 
> Example file: /usr/share/netcf/iptables-forward-bridged
> Content: -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT

(In reply to comment #33)
> As per See Also private Bug 725094, this functionality is available in
> lokkit.

See 'lokkit --custom-rules is not an appropriate integration point for libvirt' in comment #9

Closing because there will not be big changes to system-config-firewall anymore.