2019-04-12 12:41:10 +00:00
|
|
|
# vim: filetype=automake
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
NETWORK_DRIVER_SOURCES = \
|
|
|
|
|
network/bridge_driver.h \
|
|
|
|
|
network/bridge_driver.c \
|
|
|
|
|
network/bridge_driver_platform.h \
|
|
|
|
|
network/bridge_driver_platform.c \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
NETWORK_DRIVER_PLATFORM_INC = \
|
|
|
|
|
network/bridge_driver_linux.c \
|
|
|
|
|
network/bridge_driver_nop.c \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
NETWORK_LEASES_HELPER_SOURCES = \
|
|
|
|
|
network/leaseshelper.c \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
DRIVER_SOURCE_FILES += $(NETWORK_DRIVER_SOURCES)
|
|
|
|
|
STATEFUL_DRIVER_SOURCE_FILES += $(NETWORK_DRIVER_SOURCES)
|
|
|
|
|
EXTRA_DIST += \
|
|
|
|
|
$(NETWORK_DRIVER_SOURCES) \
|
|
|
|
|
$(NETWORK_DRIVER_PLATFORM_INC) \
|
|
|
|
|
$(NETWORK_LEASES_HELPER_SOURCES) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if WITH_NETWORK
|
|
|
|
|
|
|
|
|
|
noinst_LTLIBRARIES += libvirt_driver_network_impl.la
|
|
|
|
|
libvirt_driver_network_la_SOURCES =
|
|
|
|
|
libvirt_driver_network_la_LIBADD = \
|
|
|
|
|
libvirt_driver_network_impl.la \
|
|
|
|
|
libvirt.la \
|
build: link to glib library
Add the main glib.h to internal.h so that all common code can use it.
Historically glib allowed applications to register an alternative
memory allocator, so mixing g_malloc/g_free with malloc/free was not
safe.
This was feature was dropped in 2.46.0 with:
commit 3be6ed60aa58095691bd697344765e715a327fc1
Author: Alexander Larsson <alexl@redhat.com>
Date: Sat Jun 27 18:38:42 2015 +0200
Deprecate and drop support for memory vtables
Applications are still encourged to match g_malloc/g_free, but it is no
longer a mandatory requirement for correctness, just stylistic. This is
explicitly clarified in
commit 1f24b36607bf708f037396014b2cdbc08d67b275
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Sep 5 14:37:54 2019 +0100
gmem: clarify that g_malloc always uses the system allocator
Applications can still use custom allocators in general, but they must
do this by linking to a library that replaces the core malloc/free
implemenentation entirely, instead of via a glib specific call.
This means that libvirt does not need to be concerned about use of
g_malloc/g_free causing an ABI change in the public libary, and can
avoid memory copying when talking to external libraries.
This patch probes for glib, which provides the foundation layer with
a collection of data structures, helper APIs, and platform portability
logic.
Later patches will introduce linkage to gobject which provides the
object type system, built on glib, and gio which providing objects
for various interesting tasks, most notably including DBus client
and server support and portable sockets APIs, but much more too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-29 15:12:24 +00:00
|
|
|
$(GLIB_LIBS) \
|
2018-02-21 18:05:56 +00:00
|
|
|
../gnulib/lib/libgnu.la \
|
|
|
|
|
$(LIBNL_LIBS) \
|
|
|
|
|
$(DBUS_LIBS) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
mod_LTLIBRARIES += libvirt_driver_network.la
|
|
|
|
|
libvirt_driver_network_la_LDFLAGS = $(AM_LDFLAGS_MOD_NOUNDEF)
|
|
|
|
|
|
|
|
|
|
libvirt_driver_network_impl_la_CFLAGS = \
|
|
|
|
|
$(LIBNL_CFLAGS) \
|
|
|
|
|
$(DBUS_CFLAGS) \
|
|
|
|
|
-I$(srcdir)/access \
|
|
|
|
|
-I$(srcdir)/conf \
|
|
|
|
|
$(AM_CFLAGS) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
libvirt_driver_network_impl_la_SOURCES = $(NETWORK_DRIVER_SOURCES)
|
2019-07-18 14:00:54 +00:00
|
|
|
libvirt_driver_network_impl_la_LIBADD = $(DBUS_LIBS) $(LIBXML_LIBS)
|
2018-02-21 18:05:56 +00:00
|
|
|
|
2018-03-16 17:05:24 +00:00
|
|
|
sbin_PROGRAMS += virtnetworkd
|
|
|
|
|
|
|
|
|
|
nodist_conf_DATA += network/virtnetworkd.conf
|
|
|
|
|
augeas_DATA += network/virtnetworkd.aug
|
|
|
|
|
augeastest_DATA += network/test_virtnetworkd.aug
|
|
|
|
|
CLEANFILES += network/virtnetworkd.aug
|
|
|
|
|
|
|
|
|
|
virtnetworkd_SOURCES = $(REMOTE_DAEMON_SOURCES)
|
|
|
|
|
virtnetworkd_CFLAGS = \
|
|
|
|
|
$(REMOTE_DAEMON_CFLAGS) \
|
|
|
|
|
-DDAEMON_NAME="\"virtnetworkd\"" \
|
|
|
|
|
-DMODULE_NAME="\"network\"" \
|
|
|
|
|
$(NULL)
|
|
|
|
|
virtnetworkd_LDFLAGS = $(REMOTE_DAEMON_LD_FLAGS)
|
|
|
|
|
virtnetworkd_LDADD = $(REMOTE_DAEMON_LD_ADD)
|
|
|
|
|
|
|
|
|
|
SYSTEMD_UNIT_FILES += \
|
|
|
|
|
virtnetworkd.service \
|
|
|
|
|
virtnetworkd.socket \
|
|
|
|
|
virtnetworkd-ro.socket \
|
|
|
|
|
virtnetworkd-admin.socket \
|
|
|
|
|
$(NULL)
|
|
|
|
|
SYSTEMD_UNIT_FILES_IN += \
|
|
|
|
|
network/virtnetworkd.service.in \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
VIRTNETWORKD_UNIT_VARS = \
|
|
|
|
|
$(VIRTD_UNIT_VARS) \
|
|
|
|
|
-e 's|[@]name[@]|Libvirt network|g' \
|
|
|
|
|
-e 's|[@]service[@]|virtnetworkd|g' \
|
|
|
|
|
-e 's|[@]sockprefix[@]|virtnetworkd|g' \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
2019-09-23 11:31:57 +00:00
|
|
|
virtnetworkd.service: network/virtnetworkd.service.in \
|
|
|
|
|
$(top_builddir)/config.status
|
2018-03-16 17:05:24 +00:00
|
|
|
$(AM_V_GEN)$(SED) $(VIRTNETWORKD_UNIT_VARS) $< > $@-t && mv $@-t $@
|
|
|
|
|
|
2019-09-23 11:31:57 +00:00
|
|
|
virtnetwork%.socket: remote/libvirt%.socket.in \
|
|
|
|
|
$(top_builddir)/config.status
|
2018-03-16 17:05:24 +00:00
|
|
|
$(AM_V_GEN)$(SED) $(VIRTNETWORKD_UNIT_VARS) $< > $@-t && mv $@-t $@
|
|
|
|
|
|
|
|
|
|
network/virtnetworkd.conf: remote/libvirtd.conf.in
|
|
|
|
|
$(AM_V_GEN)$(SED) \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/,/[@]END[@]/d' \
|
|
|
|
|
-e 's/[@]DAEMON_NAME[@]/virtnetworkd/' \
|
|
|
|
|
$< > $@
|
|
|
|
|
|
|
|
|
|
network/virtnetworkd.aug: remote/libvirtd.aug.in
|
|
|
|
|
$(AM_V_GEN)$(SED) \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/,/[@]END[@]/d' \
|
|
|
|
|
-e 's/[@]DAEMON_NAME[@]/virtnetworkd/' \
|
|
|
|
|
-e 's/[@]DAEMON_NAME_UC[@]/Virtnetworkd/' \
|
|
|
|
|
$< > $@
|
|
|
|
|
|
|
|
|
|
network/test_virtnetworkd.aug: remote/test_libvirtd.aug.in \
|
|
|
|
|
network/virtnetworkd.conf $(AUG_GENTEST)
|
|
|
|
|
$(AM_V_GEN)$(AUG_GENTEST) network/virtnetworkd.conf \
|
|
|
|
|
$(srcdir)/remote/test_libvirtd.aug.in | \
|
|
|
|
|
$(SED) \
|
|
|
|
|
-e '/[@]CUT_ENABLE_IP[@]/,/[@]END[@]/d' \
|
|
|
|
|
-e 's/[@]DAEMON_NAME[@]/virtnetworkd/' \
|
|
|
|
|
-e 's/[@]DAEMON_NAME_UC[@]/Virtnetworkd/' \
|
|
|
|
|
> $@ || rm -f $@
|
|
|
|
|
|
2018-02-21 18:05:56 +00:00
|
|
|
libexec_PROGRAMS += libvirt_leaseshelper
|
|
|
|
|
libvirt_leaseshelper_SOURCES = $(NETWORK_LEASES_HELPER_SOURCES)
|
|
|
|
|
libvirt_leaseshelper_LDFLAGS = \
|
|
|
|
|
$(AM_LDFLAGS) \
|
|
|
|
|
$(PIE_LDFLAGS) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
libvirt_leaseshelper_LDADD = \
|
2019-05-16 08:27:45 +00:00
|
|
|
libvirt.la \
|
build: link to glib library
Add the main glib.h to internal.h so that all common code can use it.
Historically glib allowed applications to register an alternative
memory allocator, so mixing g_malloc/g_free with malloc/free was not
safe.
This was feature was dropped in 2.46.0 with:
commit 3be6ed60aa58095691bd697344765e715a327fc1
Author: Alexander Larsson <alexl@redhat.com>
Date: Sat Jun 27 18:38:42 2015 +0200
Deprecate and drop support for memory vtables
Applications are still encourged to match g_malloc/g_free, but it is no
longer a mandatory requirement for correctness, just stylistic. This is
explicitly clarified in
commit 1f24b36607bf708f037396014b2cdbc08d67b275
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Sep 5 14:37:54 2019 +0100
gmem: clarify that g_malloc always uses the system allocator
Applications can still use custom allocators in general, but they must
do this by linking to a library that replaces the core malloc/free
implemenentation entirely, instead of via a glib specific call.
This means that libvirt does not need to be concerned about use of
g_malloc/g_free causing an ABI change in the public libary, and can
avoid memory copying when talking to external libraries.
This patch probes for glib, which provides the foundation layer with
a collection of data structures, helper APIs, and platform portability
logic.
Later patches will introduce linkage to gobject which provides the
object type system, built on glib, and gio which providing objects
for various interesting tasks, most notably including DBus client
and server support and portable sockets APIs, but much more too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-29 15:12:24 +00:00
|
|
|
$(GLIB_LIBS) \
|
2018-02-21 18:05:56 +00:00
|
|
|
../gnulib/lib/libgnu.la
|
|
|
|
|
if WITH_DTRACE_PROBES
|
|
|
|
|
libvirt_leaseshelper_LDADD += libvirt_probes.lo
|
|
|
|
|
endif WITH_DTRACE_PROBES
|
|
|
|
|
|
|
|
|
|
libvirt_leaseshelper_CFLAGS = \
|
|
|
|
|
$(AM_CFLAGS) \
|
|
|
|
|
$(PIE_CFLAGS) \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
INSTALL_DATA_DIRS += network
|
|
|
|
|
|
|
|
|
|
UUID=$(shell uuidgen 2>/dev/null)
|
|
|
|
|
|
|
|
|
|
install-data-network:
|
|
|
|
|
$(MKDIR_P) "$(DESTDIR)$(localstatedir)/lib/libvirt/network"
|
|
|
|
|
$(MKDIR_P) "$(DESTDIR)$(localstatedir)/lib/libvirt/dnsmasq"
|
2019-08-20 15:08:19 +00:00
|
|
|
$(MKDIR_P) "$(DESTDIR)$(runstatedir)/libvirt/network"
|
2018-02-21 18:05:56 +00:00
|
|
|
$(MKDIR_P) "$(DESTDIR)$(confdir)/qemu/networks/autostart"
|
|
|
|
|
$(INSTALL_DATA) $(srcdir)/network/default.xml \
|
|
|
|
|
$(DESTDIR)$(confdir)/qemu/networks/default.xml
|
|
|
|
|
test -z "$(UUID)" || \
|
|
|
|
|
{ sed -e "s,</name>,</name>; <uuid>$(UUID)</uuid>," \
|
|
|
|
|
$(DESTDIR)$(confdir)/qemu/networks/default.xml | \
|
|
|
|
|
tr ";" "\n" > \
|
|
|
|
|
$(DESTDIR)$(confdir)/qemu/networks/default.xml.t && \
|
|
|
|
|
cp $(DESTDIR)$(confdir)/qemu/networks/default.xml.t \
|
|
|
|
|
$(DESTDIR)$(confdir)/qemu/networks/default.xml && \
|
|
|
|
|
rm $(DESTDIR)$(confdir)/qemu/networks/default.xml.t; }
|
|
|
|
|
( cd $(DESTDIR)$(confdir)/qemu/networks/autostart && \
|
|
|
|
|
rm -f default.xml && \
|
|
|
|
|
$(LN_S) ../default.xml default.xml )
|
configure: selectively install a firewalld 'libvirt' zone
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 and list
specific services that will be allowed into the host from guests (DNS,
DHCP, SSH, and TFTP).
But the same default accept policy that fixes forwarded traffic also
causes *all* traffic from guest to host to be accepted. To close this
new hole, the libvirt zone can take advantage of a new feature in
firewalld (currently slated for firewalld-0.7.0) - priorities for rich
rules - to add a low priority rule that rejects all local traffic (but
leaves alone all forwarded traffic).
So, our new zone will start with a list of services that are allowed
(dhcp, dns, tftp, and ssh to start, but configurable via any firewalld
management application, or direct editing of the zone file in
/etc/firewalld/zones/libvirt.xml), followed by a low priority
<reject/> rule (to reject all other traffic from guest to host), and
finally with a default policy of accept (to allow forwarded traffic).
This patch only creates the zonefile for the new zone, and implements
a configure.ac option to selectively enable/disable installation of
the new zone. A separate patch contains the necessary code to actually
place bridge interfaces in the libvirt zone.
Why do we need a configure option to disable installation of the new
libvirt zone? It uses a new firewalld attribute that sets the priority
of a rich rule; this feature first appears in firewalld-0.7.0 (unless
it has been backported to am earlier firewalld by a downstream
maintainer). If the file were installed on a system with firewalld
that didn't support rule priorities, firewalld would log an error
every time it restarted, causing confusion and lots of extra bug
reports.
So we add two new configure.ac switches to avoid polluting the system
logs with this error on systems that don't support rule priorities -
"--with-firewalld-zone" and "--without-firewalld-zone". A package
builder can use these to include/exclude the libvirt zone file in the
installation. If firewalld is enabled (--with-firewalld), the default
is --with-firewalld-zone, but it can be disabled during configure
(using --without-firewalld-zone). Targets that are using a firewalld
version too old to support the rule priority setting in the libvirt
zone file can simply add --without-firewalld-zone to their configure
commandline.
These switches only affect whether or not the libvirt zone file is
*installed* in /usr/lib/firewalld/zones, but have no effect on whether
or not libvirt looks for a zone called libvirt and tries to use it.
NB: firewalld zones can only be added to the permanent config of
firewalld, and won't be loaded/enabled until firewalld is restarted,
so at package install/upgrade time we have to restart firewalld. For
rpm-based distros, this is done in the libvirt.spec file by calling
the %firewalld_restart rpm macro, which is a part of the
firewalld-filesystem package. (For distros that don't use rpm
packages, the command "firewalld-cmd --reload" will have the same
effect).
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
|
|
|
if WITH_FIREWALLD_ZONE
|
|
|
|
|
$(MKDIR_P) "$(DESTDIR)$(prefix)/lib/firewalld/zones"
|
|
|
|
|
$(INSTALL_DATA) $(srcdir)/network/libvirt.zone \
|
|
|
|
|
$(DESTDIR)$(prefix)/lib/firewalld/zones/libvirt.xml
|
|
|
|
|
endif WITH_FIREWALLD_ZONE
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
uninstall-data-network:
|
|
|
|
|
rm -f $(DESTDIR)$(confdir)/qemu/networks/autostart/default.xml
|
|
|
|
|
rm -f $(DESTDIR)$(confdir)/qemu/networks/default.xml
|
|
|
|
|
rmdir "$(DESTDIR)$(confdir)/qemu/networks/autostart" || :
|
|
|
|
|
rmdir "$(DESTDIR)$(confdir)/qemu/networks" || :
|
|
|
|
|
rmdir "$(DESTDIR)$(localstatedir)/lib/libvirt/network" ||:
|
2019-08-20 15:08:19 +00:00
|
|
|
rmdir "$(DESTDIR)$(runstatedir)/libvirt/network" ||:
|
configure: selectively install a firewalld 'libvirt' zone
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 and list
specific services that will be allowed into the host from guests (DNS,
DHCP, SSH, and TFTP).
But the same default accept policy that fixes forwarded traffic also
causes *all* traffic from guest to host to be accepted. To close this
new hole, the libvirt zone can take advantage of a new feature in
firewalld (currently slated for firewalld-0.7.0) - priorities for rich
rules - to add a low priority rule that rejects all local traffic (but
leaves alone all forwarded traffic).
So, our new zone will start with a list of services that are allowed
(dhcp, dns, tftp, and ssh to start, but configurable via any firewalld
management application, or direct editing of the zone file in
/etc/firewalld/zones/libvirt.xml), followed by a low priority
<reject/> rule (to reject all other traffic from guest to host), and
finally with a default policy of accept (to allow forwarded traffic).
This patch only creates the zonefile for the new zone, and implements
a configure.ac option to selectively enable/disable installation of
the new zone. A separate patch contains the necessary code to actually
place bridge interfaces in the libvirt zone.
Why do we need a configure option to disable installation of the new
libvirt zone? It uses a new firewalld attribute that sets the priority
of a rich rule; this feature first appears in firewalld-0.7.0 (unless
it has been backported to am earlier firewalld by a downstream
maintainer). If the file were installed on a system with firewalld
that didn't support rule priorities, firewalld would log an error
every time it restarted, causing confusion and lots of extra bug
reports.
So we add two new configure.ac switches to avoid polluting the system
logs with this error on systems that don't support rule priorities -
"--with-firewalld-zone" and "--without-firewalld-zone". A package
builder can use these to include/exclude the libvirt zone file in the
installation. If firewalld is enabled (--with-firewalld), the default
is --with-firewalld-zone, but it can be disabled during configure
(using --without-firewalld-zone). Targets that are using a firewalld
version too old to support the rule priority setting in the libvirt
zone file can simply add --without-firewalld-zone to their configure
commandline.
These switches only affect whether or not the libvirt zone file is
*installed* in /usr/lib/firewalld/zones, but have no effect on whether
or not libvirt looks for a zone called libvirt and tries to use it.
NB: firewalld zones can only be added to the permanent config of
firewalld, and won't be loaded/enabled until firewalld is restarted,
so at package install/upgrade time we have to restart firewalld. For
rpm-based distros, this is done in the libvirt.spec file by calling
the %firewalld_restart rpm macro, which is a part of the
firewalld-filesystem package. (For distros that don't use rpm
packages, the command "firewalld-cmd --reload" will have the same
effect).
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
|
|
|
if WITH_FIREWALLD_ZONE
|
|
|
|
|
rm -f $(DESTDIR)$(prefix)/lib/firewalld/zones/libvirt.xml
|
|
|
|
|
endif WITH_FIREWALLD_ZONE
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
endif WITH_NETWORK
|
|
|
|
|
|
configure: selectively install a firewalld 'libvirt' zone
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 and list
specific services that will be allowed into the host from guests (DNS,
DHCP, SSH, and TFTP).
But the same default accept policy that fixes forwarded traffic also
causes *all* traffic from guest to host to be accepted. To close this
new hole, the libvirt zone can take advantage of a new feature in
firewalld (currently slated for firewalld-0.7.0) - priorities for rich
rules - to add a low priority rule that rejects all local traffic (but
leaves alone all forwarded traffic).
So, our new zone will start with a list of services that are allowed
(dhcp, dns, tftp, and ssh to start, but configurable via any firewalld
management application, or direct editing of the zone file in
/etc/firewalld/zones/libvirt.xml), followed by a low priority
<reject/> rule (to reject all other traffic from guest to host), and
finally with a default policy of accept (to allow forwarded traffic).
This patch only creates the zonefile for the new zone, and implements
a configure.ac option to selectively enable/disable installation of
the new zone. A separate patch contains the necessary code to actually
place bridge interfaces in the libvirt zone.
Why do we need a configure option to disable installation of the new
libvirt zone? It uses a new firewalld attribute that sets the priority
of a rich rule; this feature first appears in firewalld-0.7.0 (unless
it has been backported to am earlier firewalld by a downstream
maintainer). If the file were installed on a system with firewalld
that didn't support rule priorities, firewalld would log an error
every time it restarted, causing confusion and lots of extra bug
reports.
So we add two new configure.ac switches to avoid polluting the system
logs with this error on systems that don't support rule priorities -
"--with-firewalld-zone" and "--without-firewalld-zone". A package
builder can use these to include/exclude the libvirt zone file in the
installation. If firewalld is enabled (--with-firewalld), the default
is --with-firewalld-zone, but it can be disabled during configure
(using --without-firewalld-zone). Targets that are using a firewalld
version too old to support the rule priority setting in the libvirt
zone file can simply add --without-firewalld-zone to their configure
commandline.
These switches only affect whether or not the libvirt zone file is
*installed* in /usr/lib/firewalld/zones, but have no effect on whether
or not libvirt looks for a zone called libvirt and tries to use it.
NB: firewalld zones can only be added to the permanent config of
firewalld, and won't be loaded/enabled until firewalld is restarted,
so at package install/upgrade time we have to restart firewalld. For
rpm-based distros, this is done in the libvirt.spec file by calling
the %firewalld_restart rpm macro, which is a part of the
firewalld-filesystem package. (For distros that don't use rpm
packages, the command "firewalld-cmd --reload" will have the same
effect).
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-01-26 04:52:37 +00:00
|
|
|
EXTRA_DIST += network/default.xml network/libvirt.zone
|
2018-02-21 18:05:56 +00:00
|
|
|
|
|
|
|
|
.PHONY: \
|
|
|
|
|
install-data-network \
|
|
|
|
|
uninstall-data-network \
|
|
|
|
|
$(NULL)
|
