New Package Request: firewalld

[hrismarin]

What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc)

Added:
  firewalld-2.1.2-2.fc40.noarch
  firewalld-filesystem-2.1.2-2.fc40.noarch
  gobject-introspection-1.80.1-1.fc40.x86_64
  ipset-7.21-1.fc40.x86_64
  ipset-libs-7.21-1.fc40.x86_64
  libb2-0.98.1-11.fc40.x86_64
  libcap-ng-python3-0.8.4-4.fc40.x86_64
  libgomp-14.1.1-4.fc40.x86_64
  mpdecimal-2.5.1-9.fc40.x86_64
  python-pip-wheel-23.3.2-1.fc40.noarch
  python-unversioned-command-3.12.3-2.fc40.noarch
  python3-3.12.3-2.fc40.x86_64
  python3-dbus-1.3.2-6.fc40.x86_64
  python3-firewall-2.1.2-2.fc40.noarch
  python3-gobject-base-3.48.2-1.fc40.x86_64
  python3-libs-3.12.3-2.fc40.x86_64
  python3-nftables-1:1.0.9-3.fc40.x86_64

What is the size of the package and its dependencies?

firewalld                        2,2M
firewalld-filesystem             239
gobject-introspection            322K
ipset                            76K
ipset-libs                       213K
libb2                            42K
libcap-ng-python3                68K
libgomp                          520K
mpdecimal                        201K
python-pip-wheel                 1,5M
python-unversioned-command       23
python3                          32K
python3-dbus                     523K
python3-firewall                 3,0M
python3-gobject-base             1,4M
python3-libs                     41M
python3-nftables                 45K

What problem are you trying to solve with this package? Or what functionality does the package provide?

firewalld provides advantages over iptables/nftables such as dynamically managed firewall, ability to not care what the backend is, support for network/firewall zones, etc.

Can the software provided by the package be run from a container? Explain why or why not.

Yes, in Kubernetes environments as part of a security stack.

Can the tool(s) provided by the package be helpful in debugging container runtime issues?

Yes, indirectly if enabled.

Can the tool(s) provided by the package be helpful in debugging networking issues?

Yes.

Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not.

firewalld can be installed both when first booting via Ignition and later.

In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries?

N/A

Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS?

No.

Does the software provided by the package have a history of CVEs?

Yes.

[travier]

Have you tried running it from a privileged container?

[hrismarin]

I haven't but I'll try. Is there any documentation, other than the official one from Podman that you can direct me to?

[dustymabe]

The dependency list here seems large as this would be the first new package to include python. If we can get past that I think the question to ask ourselves is if we think this is basic functionality we have been missing or not.

I think firewalld vs iptables/nftables for me is analogous to NetworkManager vs ip. You can bring your network up using just ip commands but NetworkManager makes it more approachable and easier to manage.

Another way to ask this question is: if firewalld wasn't built on top of python, would we have included it from the start of FCOS?

[dustymabe]

Another point to mention here:

In most cloud environments users most likely rely on cloud firewalling (i.e. security groups) so this is of limited use there. Where this is important is bare metal use cases or more loosely managed or unmanaged environments.

[hrismarin]

Where this is important is bare metal use cases or more loosely managed or unmanaged environments.

This is my main reason for the request. I'm not sure how many of the FCOS deployments are on bare metal or home servers/labs. Adding firewalld to the base image will make FCOS even more attractive and easy to use in such environments.

An additional benefit would be the availability of Python, which would allow management of FCOS nodes by Ansible out of the box.

[yasminvalim]

We decided during today's FCOS meeting to postpone this discussion until the next meeting to ensure more participants, many of whom are currently attending DevConf, can join.

[jlebon]

Just playing around with running it in a container, it seems to work fine in some quick tests:

FROM quay.io/fedora/fedora:40
RUN dnf install -y systemd firewalld && \
    dnf clean all && \
    systemctl enable firewalld
CMD ["/sbin/init"]

$ sudo podman run -d --net=host --privileged --name firewalld localhost/firewalld
$ sudo podman exec firewalld firewall-cmd --state
running
$ sudo nft list tables
table ip nat
table ip filter
table inet firewalld
$ sudo podman exec firewalld firewall-cmd --add-service=ftp
success
$ sudo podman exec firewalld firewall-cmd --add-port=60000/tcp
success
$ nft list table inet firewalld | grep accept | grep -e 21 -e 60000
                tcp dport 21 accept
                tcp dport 60000 accept

You'd probably want to mount e.g. /etc/firewalld and maybe /etc/nftables but it seems to work fine offhand.

Of course though a downside of this is when provisioning you'd start with no firewall until you can download and start up the container. Though OTOH the list of services that listen by default is quite limited and actively checked in CI.

And of course there's also layering eventually if you just want it on the host.

So I think the more important question is:

if we think this is basic functionality we have been missing or not.

I think it'd be nice to have built-in, but I don't see it as essential IMO. Yes, bare metal is a primary target, but it's hard to ignore that it'd just sit there taking up space on disk and in transit in cloud instances. Also ISTM like a firewall is not so much for our built-in services (yes, could make sense to e.g. IP-restrict incoming SSH connections, but...) but rather services coming from layered packages/derived builds, or containers with exposed ports. At that point, one could choose to also layer firewalld or run it in a container.

[travier]

On Fedora CoreOS, we expect users to run their services inside containers. When you run applications inside containers, those are connected to an local internal network by default and are not exposed to the network. You usually control which ports are exposed to the network using the --publish option.

This means that adding any firewall configuration for incoming connections will usually duplicate those container runtime configuration, without any additional security benefit. As far as I know, neither podman nor docker interacts with firewalld. I found https://fale.io/blog/2023/02/24/podman-ports-and-firewalld (but I did not dig deeper).

Firewalld is mostly designed around a set of pre-defined rules for well-known services with known-in-advance ports to open. This often do not apply to services running in containers as those may listen on any port or you may publish ports from the container network to different ports on the host and thus to different ports than the ones that are expected by the firewalld configuration.

As far as I know, Firewalld does not manage outgoing traffic (https://serverfault.com/questions/618164/block-outgoing-connections-on-rhel7-centos7-with-firewalld, https://www.ispcolohost.com/2016/07/25/blocking-outgoing-ports-with-firewalld/) thus setting this up is very similar to setting iptables/nftables rules manually.

Overall, I see very little use cases where firewalld would bring something useful to Fedora CoreOS right now, so I don't think we should include it by default.

Layering it or running it from a privileged container should cover the cases where it's a good fit.

[erig0]

Hi everyone. Firewalld maintainer speaking. I hope I can clarify some points here.

Just playing around with running it in a container, it seems to work fine in some quick tests:

I hope so! The entire firewalld testsuite runs inside of network namespaces. Additionally the upstream testsuite has a few "check container" targets that run via podman/docker.

As far as I know, neither podman nor docker interacts with firewalld.

Both do to varying degrees.

The latest Podman has native firewalld support (marked experimental). Older podman had partial integration. Docker has partial integration. Partial integration basically means "do most of the work in iptables, but also interact with firewalld enough to open a hole".

I found https://fale.io/blog/2023/02/24/podman-ports-and-firewalld (but I did not dig deeper).

This topic has come up a lot. I've discussed it with the podman team many times. The short is that many users expect "magic" and others expect "strict". Changing that behavior would break many people. I wrote this blog for those that want "strict".

https://firewalld.org/2024/04/strictly-filtering-docker-containers

you may publish ports from the container network to different ports on the host and thus to different ports than the ones that are expected by the firewalld configuration.

This is exactly why --add-forward-port exists.

As far as I know, Firewalld does not manage outgoing traffic

It has since v0.9.0 (2020).

https://firewalld.org/2020/09/policy-objects-introduction

[jlebon]

Just playing around with running it in a container, it seems to work fine in some quick tests:

I hope so! The entire firewalld testsuite runs inside of network namespaces. Additionally the upstream testsuite has a few "check container" targets that run via podman/docker.

Thanks for chiming in! I also see now https://quay.io/repository/firewalld/firewalld. (I had checked before doing my own testing for an official image on Docker Hub and missed checking Quay.io as well.)

I was surprised by that podman run command; I would've expected to see bind-mounts for e.g. D-Bus, and possibly some /etc subdirs too. But then from https://github.com/firewalld/firewalld?tab=readme-ov-file#oci-container-image, I see:

The containerized firewalld will not integrate with the host (e.g. podman, libvirt, NetworkManager).

Is there a fundamental limitation there or do you expect it to work if the container is exposed enough?

[erig0]

Just playing around with running it in a container, it seems to work fine in some quick tests:

I hope so! The entire firewalld testsuite runs inside of network namespaces. Additionally the upstream testsuite has a few "check container" targets that run via podman/docker.

Thanks for chiming in! I also see now https://quay.io/repository/firewalld/firewalld. (I had checked before doing my own testing for an official image on Docker Hub and missed checking Quay.io as well.)

I was surprised by that podman run command; I would've expected to see bind-mounts for e.g. D-Bus, and possibly some /etc subdirs too. But then from https://github.com/firewalld/firewalld?tab=readme-ov-file#oci-container-image, I see:

The upstream README talks about this.

https://github.com/firewalld/firewalld/?tab=readme-ov-file#container-integration-with-host

The containerized firewalld will not integrate with the host (e.g. podman, libvirt, NetworkManager).

Is there a fundamental limitation there or do you expect it to work if the container is exposed enough?

No. It just requires more work, e.g. dbus configuration on the host. Which then becomes a non-self contained container image. That kind of defeats the purpose, IMO.

[c4rt0]

This was discussed at the Fedora meeting yesterday. Summary:

Currently, we are not considering adding firewalld by default. We will however add documentation detailing the rationale for this, as well as every port open by default, example nftables configs, and instructions on how to add firewalld to the host.

[jlebon]

@travier captured the documentation bits in https://github.com/coreos/fedora-coreos-docs/issues/247#issuecomment-2221079348.

So I think we can close this? Feel free to reopen if I'm missing something.