[libvirt] [PATCH v2 4/7] configure: selectively install a firewalld 'libvirt' zone

[Daniel P. Berrangé]

On Thu, Jan 31, 2019 at 08:24:55PM -0500, Laine Stump wrote:
> In the past (when both libvirt and firewalld used iptables), if either
> libvirt's rules *OR* firewalld's rules accepted a packet, it would
> be accepted. This was because libvirt and firewalld rules were
> processed during the same kernel hook, and a single ACCEPT result
> would terminate the rule traversal and cause the packet to be
> accepted.
> 
> But now firewalld can use nftables for its backend, while libvirt's
> firewall rules are still using iptables; iptables rules are still
> processed, but at a different time during packet processing
> (i.e. during a different hook) than the firewalld nftables rules. The
> result is that a packet must be accepted by *BOTH* the libvirt
> iptables rules *AND* the firewalld nftable rules in order to be
> accepted.
> 
> This causes pain because
> 
> 1) libvirt always adds rules to permit DNS and DHCP (and sometimes
> TFTP) from guests to the host network's bridge interface. But
> libvirt's bridges are in firewalld's "default" zone (which is usually
> the zone called "public"). The public zone allows ssh, but doesn't
> allow DNS, DHCP, or TFTP. So even though libvirt's rules allow the
> DHCP and DNS traffic, the firewalld rules (now processed during a
> different hook) dont, thus guests connected to libvirt's bridges can't
> acquire an IP address from DHCP, nor can they make DNS queries to the
> DNS server libvirt has setup on the host. (This could be solved by
> modifying the default firewalld zone to allow DNS and DHCP, but that
> would open *all* interfaces in the default zone to those services,
> which is most likely not what the host's admin wants.)
> 
> 2) Even though libvirt adds iptables rules to allow forwarded traffic
> to pass the iptables hook, firewalld's higher level "rich rules" don't
> yet have the ability to configure the acceptance of forwarded traffic
> (traffic that is going somewhere beyond the host), so any traffic that
> needs to be forwarded from guests to the network beyond the host is
> rejected during the nftables hook by the default zone's "default
> reject" policy (which rejects all traffic in the zone not specifically
> allowed by the rules in the zone, whether that traffic is destined to
> be forwarded or locally received by the host).
> 
> libvirt can't send "direct" nftables rules (firewalld only supports
> direct/passthrough rules for iptables), so we can't solve this problem
> by just sending explicit nftables rules instead of explicit iptables
> rules (which, if it could be done, would place libvirt's rules in the
> same hook as firewalld's native rules, and thus eliminate the need for
> packets to be accepted by both libvirt's and firewalld's own rules).
> 
> However, we can take advantage of a quirk in firewalld zones that have
> a default policy of "accept" (meaning any packet that doesn't match a
> specific rule in the zone will be *accepted*) - this default accept will
> also accept forwarded traffic (not just traffic destined for the host).
> 
> Of course we don't want to modify firewalld's default zone in that
> way, because that would affect the filtering of traffic coming into
> the host from other interfaces using that zone. Instead, we will
> create a new zone called "libvirt". The libvirt zone will have a
> default policy of accept so that forwarded traffic can pass andn list

s/andn/and/

> specific services that will be allowed into the host from guests (DNS,
> DHCP, SSH, and TFTP).

Reviewed-by: Daniel P. Berrangé <berrange at redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|