Re: Fedora 32 System-Wide Change proposal: Firewalld Default to nftables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Dec 28, 2019 at 8:00 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Mon, Sep 9, 2019 at 3:32 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
> >
> > https://fedoraproject.org/wiki/Changes/firewalld_default_to_nftables
> >
> > == Summary ==
> > This change will toggle the default firewalld backend from iptables to
> > nftables. All of firewalld's primitives will use nftables while direct
> > rules continue to use iptables/ebtables.
> >
> > == Owner ==
> > * Name: [[User:erig0| Eric Garver]]
> > * Email: egarver@xxxxxxxxxx
> >
> >
> > == Detailed Description ==
> > Firewalld upstream has used nftables as the default backend for the
> > past two minor releases. It is also the default in other distributions
> > (e.g. RHEL-8). This change will bring Fedora in line with upstream.
> >
> > Using nftables bring many advantages. See firewalld's upstream
> > [https://firewalld.org/2018/07/nftables-backend blog post]. It also
> > highlights a few behavioral changes.
> >
> > == Benefit to Fedora ==
> > * Fewer firewall rules (rule consolidation)
> > All of firewalld's primitives will use the same underlying firewall
> > (nftables) instead of duplicating rules both in iptables and
> > ip6tables. In nftables rules can match both IPv4 and IPv6 packets.
> > This reduces the number of firewall rules by half.
> > * firewalld's rules are namespaced
> > With nftables firewalld's rules are isolated to a "firewalld" table. A
> > separate firewall (or user) can create its own independent ruleset and
> > firewalld will never touch it.
> > * Netfilter upstream is focusing on nftables, not iptables
> >
> > == Scope ==
> > * Proposal owners: firewalld (erig0, Eric Garver)
> > Currently the firewalld package has a Fedora downstream patch to hide
> > the nftables backend. The only firewalld change required is to remove
> > that patch from the package and rebuild.
> >
> > * Other developers: libvirt, podman, docker
> > ** libvirt
> > *** libvirt already cooperates with the firewalld nftables backend.
> > The only thing needed is to test/verify.
> > ** podman
> > *** libvirt already cooperates with the firewalld nftables backend.
> > The only thing needed is to test/verify.
> > ** docker
> > *** Docker currently does not cooperate with the nftables backend. It
> > currently side-steps firewalld by injecting its own rules in iptables
> > ahead of firewalld's rules. However, with the nftables backend
> > firewalld's rule will still be evaluated. Netfilter in the kernel will
> > call iptables, then nftables for the same packet. This means
> > firewalld/nftables is likely to drop the packet even if docker has
> > iptables rules to ACCEPT.
> > *** Proposed fix 1: Docker package should provide a firewalld zone
> > definition that includes the docker interfaces (e.g. docker0). The
> > zone should use the "ACCEPT" policy (firewalld --set-target). This
> > will allow docker's traffic to pass through firewalld/nftables.
> > **** Issue 1: If a user has configured a different docker bridge name,
> > then they'll have to manually add the bridge to the docker zone (or
> > firewalld's trusted zone).
> > *** Proposed fix 2: Just like "Proposed fix 1", but instead of adding
> > the zone definition to docker we created a "docker-firewalld" (or
> > firewalld-docker?) package that has the zone definition. This could be
> > installed by default when docker is installed.
> > * Policies and guidelines: No updated needed.
> > * Trademark approval: N/A (not needed for this Change)
> >
> >
> > == Upgrade/compatibility impact ==
> > When users are upgraded to firewalld with nftables enabled (f32) all
> > their firewall rules will exist in nftables instead of iptables. All
> > of firewalld's primitives (zones, services, ports, rich rules, etc.)
> > are 100% compatible between backends.
> >
> > Users of direct rules may need to consider the
> > [https://firewalld.org/2018/07/nftables-backend behavioral changes]
> > that were announced upstream. Some are also highlighted here:
> >
> > * direct rules execute before _all_ firewalld rules
> > ** This has been requested by users
> > * packets dropped in iptables (or direct rules) will never be seen by firewalld
> > * packets accepted in iptables (or direct rules) are still subject to
> > firewalld's rules
> >
> > == How To Test ==
> > Testing should mostly be integration based. Firewalld upstream has a
> > fairly comprehensive testsuite that covers functional testing.
> >
> > The following are packages known to integrate with firewalld. They
> > should be tested with the nftables backend.
> >
> > * libvirt
> > ** verify VMs with different network types (bridged, routed) have
> > working network access
> > ** newer version of libvirt should create and use a "libvirt"
> > firewalld zone. Interfaces should be dynamically added to the zone.
> > * podman
> > ** verify podman adds container bridge interface to the "trusted" zone
> > ** verify container still has network access
> > * docker
> > ** known to not work with the firewalld nftables backend out of the box
> > ** verify new package docker-firewalld installs firewalld docker zone
> > and has "docker0" interface added
> > ** verify container still has network access
> > * fail2ban-firewalld
> > ** verify the direct rules added to firewalld by fail2ban still block traffic
> >
> > == User Experience ==
> > In general users shouldn't notice the change. Occasional a user will
> > look at the iptables rule that firewalld generates. They'll now have
> > to look at nftables instead.
> >
> > == Dependencies ==
> > * libvirt >= 5.1.0
> > * CNI >= 0.8.0 (used by podman)
> > * docker-firewalld (new package)
> >
> > == Contingency Plan ==
> > * Contingency mechanism: firewalld maintainer (erig0) will reinstate
> > the current patch to default to the iptables backend.
> > * Contingency deadline: beta freeze
> >
> > == Documentation ==
> > * [https://firewalld.org/2018/07/nftables-backend Firewalld blog post]
> >
>
> I realize I'm commenting quite late on this and it's already been
> accepted, but did anyone realize that nspawn and networkd were not
> compatible with firewalld in nftables mode? I didn't until it came up
> in the Mageia dev mailing list[1], where someone tried to build a
> firewalld-based firewall on a Mageia-based server using networkd for
> network management and firewall rules were not working because
> systemd's firewall-util functions are using libiptc instead of
> libnftables. There's an upstream bug report on systemd about it,
> too[2]. This needs to be addressed in some manner before Fedora 32
> beta freeze...

There's a contingency if such things must work and can't be fixed
before beta freeze, so I don't think it's too late. I'm also just
stumbling on a showstopper bug related to this, VM's won't start while
firewalld is running.

https://bugzilla.redhat.com/show_bug.cgi?id=1786876


-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux