Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firewalld only assigns interface zone in NetworkManager in the CLI script #1265

Open
darius-m opened this issue Dec 16, 2023 · 3 comments
Open
Labels
triage Issue needs triaged.

Comments

@darius-m
Copy link

darius-m commented Dec 16, 2023

What happened

NetworkManager can override an interface's zone configuration, even if the interface is permanently attributed in firewalld's zone file. This causes some issues that were mitigated by also configuring the zone in NetworkManager when the running firewall-cmd --permanent, using NetworkManager's configuration API, back in commit e83ae42. However, this action is only performed when running firewall-cmd in the CLI. Tools that instead use the firewall Python module directly do not get the same results - the issue has been reported to both in this repository (in #1088) and in the Ansible posix module library (ansible-collections/ansible.posix#357, ansible-collections/ansible.posix#75).

For example on a CentOS Stream 9 (or another RHEL derivative) system, use the Ansible firewalld module to permanently assign an interface's zone - e.g. ansible localhost -m firewalld -a 'zone=work interface=eth0 state=enabled permanent=yes immediate=yes'.

The interface is assigned to the zone correctly in the runtime configuration, but the configuration does not persist across reboots (or NetworkManager service restarts), even if firewall-cmd --permanent --list-all-zones mentions the interface as part of the new zone. However, when using firewall-cmd --permanent --add-interface=eth0 --zone=work && firewall-cmd --reload, firewall-cmd also configures the interface's zone in NetworkManager, so the configuration persists across reboots.

What you expected to happen

The NetworkManager configuration should be performed in the firewall Python module, not just as part of the CLI script, as the issue is not specific to the CLI. Other tools that use the library (e.g. the firewalld Ansible module) that do not explicitly call the NetworkManager functions should get the same results from the firewall library as the firewall-cmd tool.

How to reproduce it (as minimally and precisely as possible)

ansible localhost -m firewalld -a 'zone=work interface=eth0 state=enabled permanent=yes immediate=yes'

has a different restult from

firewall-cmd --permanent --add-interface=eth0 --zone=work && firewall-cmd --reload

Anything else we need to know?

No response

Firewalld Version

1.2.5

Firewalld Backend

nftables

Linux distribution

Centos Stream 9

Linux kernel version

5.14.0-391.el9.x86_64

Other information

No response

@darius-m darius-m added the triage Issue needs triaged. label Dec 16, 2023
@erig0
Copy link
Collaborator

erig0 commented Dec 16, 2023

The NetworkManager configuration should be performed in the firewall Python module, not just as part of the CLI script, as the issue is not specific to the CLI.

The nuance here is polkit authorization. If the request is done by the firewalld daemon, then it's not representative of the user making the request via firewall-cmd (or ansible). This means NetworkManager can't apply any reasonable policy for modifying the connections (ZONE) setting; it would always appear to come from the user firewalld runs as, i.e. root.

My guess is the above is why it's done by the UI and not the daemon.

So the question becomes, does it make sense to allow firewalld the daemon to modify NetworkManager's connection profiles. It may side-step NM's existing polkit policies.

I'm not sure it makes sense for firewalld (client or daemon) to forward these requests to NM on behalf of the user. It would be better to configure them through NetworkManager directly, but then users are confused because NM will alter the interface to zone assignment at runtime; overriding firewalld's own configuration. This NM integration has been in firewalld for a long time. We can't just drop it.

@thom311, any thoughts?

@darius-m
Copy link
Author

Is it possible to run the firewall Python module without root access? If not, I don't see a reason why firewalld wouldn't go through with the changes at library level, instead of CLI level, since in the end the result would be the same, as you'd still have to run the firewalld commands as root. You also wouldn't violate NetworkManager's polkit policies, since they cannot offer capabilities that root does not have (as far as I know, there might be some niche interactions in SELinux or other other security modules).

@erig0
Copy link
Collaborator

erig0 commented Dec 18, 2023

Is it possible to run the firewall Python module without root access?

Yes. It's possible to specify and customize the polkit authorization. In practice (default) config changes require root, but they don't have to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage Issue needs triaged.
Projects
None yet
Development

No branches or pull requests

2 participants