Bug 1147499

Summary: RFE: use firewalld for dynamic firewal configuration
Product: Red Hat Enterprise Linux 7 Reporter: David Jaša <djasa>
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.1CC: dyuan, fschwarz, honzhang, libvirt-maint, mzhan, rbalakri
Target Milestone: rcKeywords: FutureFeature
Target Release: 7.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 969177 Environment:
Last Closed: 2015-07-13 15:29:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 969177    
Bug Blocks:    

Description David Jaša 2014-09-29 12:18:10 UTC 
+++ This bug was initially created as a clone of Bug #969177 +++

Description of problem:
While libvirt has it's own powerfult firewall driver, it would be nice if it could play nicely with firewalld - use it's native interfaces to tell it to open a port when libvirt-managed VM starts listening on it and tell it to filter the port again when the port is not in use anymore.

Using firewalld means that other apps in need of dynamic port opening/closing means that they can ask for their ports, too, without any configuration races etc.

Version-Release number of selected component (if applicable):
1.0

+++ end clone +++


RHEL 7.1, libvirt version: libvirt-1.2.8-2


Addendum:
currently, there are at least these ranges used by qemu VMs:

grep 'port_m' /etc/libvirt/qemu.conf
#remote_display_port_min = 5900
#remote_display_port_max = 65535
#remote_websocket_port_min = 5700
#remote_websocket_port_max = 65535
#migration_port_min = 49152
#migration_port_max = 49215

It would be cool for libvirt not to need to have wide subsets of these ranges opened in order to fully function but instead have firewalld do this job in the runtime
Comment 1 Michal Privoznik 2015-07-13 15:29:43 UTC 
(In reply to David Jaša from comment #0)
> +++ This bug was initially created as a clone of Bug #969177 +++
> 
> Description of problem:
> While libvirt has it's own powerfult firewall driver, it would be nice if it
> could play nicely with firewalld - use it's native interfaces to tell it to
> open a port when libvirt-managed VM starts listening on it and tell it to
> filter the port again when the port is not in use anymore.
> 
> Using firewalld means that other apps in need of dynamic port
> opening/closing means that they can ask for their ports, too, without any
> configuration races etc.

I am afraid this is not feasible. I mean, this kind of requests often pops up on the upstream list and we reject it immediatelly. You certainly don't want a deamon on your host opening a random ports in your firewall. It crosses the purpose of the firewall, which is - even if one runs a buggy application (e.g. a backdoor), which opens random ports, attacker is unable to connect as long as a box in the middle don't let the connection through. In this case, the box is - you guessed it - a firewall.

> 
> Version-Release number of selected component (if applicable):
> 1.0
> 
> +++ end clone +++
> 
> 
> RHEL 7.1, libvirt version: libvirt-1.2.8-2
> 
> 
> Addendum:
> currently, there are at least these ranges used by qemu VMs:
> 
> grep 'port_m' /etc/libvirt/qemu.conf
> #remote_display_port_min = 5900
> #remote_display_port_max = 65535
> #remote_websocket_port_min = 5700
> #remote_websocket_port_max = 65535
> #migration_port_min = 49152
> #migration_port_max = 49215
> 
> It would be cool for libvirt not to need to have wide subsets of these
> ranges opened in order to fully function but instead have firewalld do this
> job in the runtime

The idea to make these ranges configurable was to allow sysadmins choose the shortest range needed.