Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1054296

Summary:	[RFE] RHEVM should use its own iptables (whatever other FW is) chain
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Jiri Belka <jbelka>
Component:	ovirt-engine-setup	Assignee:	Yedidyah Bar David <didi>
Status:	CLOSED WONTFIX	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.3.0	CC:	acathrow, bazulay, gklein, iheim, Rhev-m-bugs, sbonazzo, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	integration
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-05 11:07:35 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:

Description Jiri Belka 2014-01-16 15:02:29 UTC

Description of problem:
During upgrade rhevm-setup stops fw (iptables) service, thus it cleans all fw rules.

I feel scared I would be hacked by NSA and others :D

FW rules between "system" and RHEVM should be split, during RHEVM upgrade when rhevm-setup clears FW rules, it could make other services exposing to remote network access and which could not be desirable.

Also clear split would make it easier to manipulate FW rules generally. Cleaning own chain would be more secure than to mess with all FW rules.

(Well maybe all RHEVM apps thus should have one place to define their listening ports, so rhevm-setup/RC scripts could take care of FW rules; it would be much better than to parse couple of plain-text configuration files.)

Version-Release number of selected component (if applicable):
is32.2

How reproducible:
100%

Steps to Reproduce:
1. do upgrade
2. check log to see how fw rules were flushed for a while and machine was "open" to any access
3.

Actual results:
rhevm-setup makes server "open" to any access for a while during upgrade

Expected results:
clear only RHEVM specific FW rules during upgrade, RHEVM daemons are down anyway, but never touch/mess with FW rules related to other daemons/whatever...

Additional info:

Comment 1 Jiri Belka 2014-01-16 15:15:29 UTC

For example /etc/sysconfig/nfs defines listening ports for all related NFS daemons, thus we have got used to that to have _one_ file with ports definitions for multiple daemons.

Comment 2 Yedidyah Bar David 2014-08-05 11:07:35 UTC

(In reply to Jiri Belka from comment #0)
> Description of problem:
> During upgrade rhevm-setup stops fw (iptables) service, thus it cleans all
> fw rules.
> 
> I feel scared I would be hacked by NSA and others :D

engine-setup just restarts the iptables service. It does not stop, then does some things (which might take a long time), then starts.

> 
> FW rules between "system" and RHEVM should be split, during RHEVM upgrade
> when rhevm-setup clears FW rules, it could make other services exposing to
> remote network access and which could not be desirable.

If manipulating the firewall is not desirable by user, just reply "no" when asked about that.

> 
> Also clear split would make it easier to manipulate FW rules generally.
> Cleaning own chain would be more secure than to mess with all FW rules.
> 
> (Well maybe all RHEVM apps thus should have one place to define their
> listening ports, so rhevm-setup/RC scripts could take care of FW rules; it
> would be much better than to parse couple of plain-text configuration files.)

I agree that parsing /etc/sysconfig/iptables and trying to figure out what was set by default, what was a result of using some system tools, what was manually set by admin, and what was added by us (also perhaps later edited by admin) is unrealistic.

I do not know of any other service that manipulates iptables at *runtime*, rather than editing /etc/sysconfig/iptables (if at all).

> 
> Version-Release number of selected component (if applicable):
> is32.2
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. do upgrade
> 2. check log to see how fw rules were flushed for a while and machine was
> "open" to any access

Can't see this. I see:

2014-08-05 12:33:21 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:785 execute: ('/sbin/service', 'iptables', 'stop'), executable='None', cwd='None', env=None
...
2014-08-05 12:33:22 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:785 execute: ('/sbin/service', 'iptables', 'start'), executable='None', cwd='None', env=None


(In reply to Jiri Belka from comment #1)
> For example /etc/sysconfig/nfs defines listening ports for all related NFS
> daemons, thus we have got used to that to have _one_ file with ports
> definitions for multiple daemons.

Didn't understand this example. Does the nfs system add/edit/remove relevant lines from /etc/sysconfig/iptables? Or does that at daemons start? Does it deal properly with manual changes done by the user? If so, we can consider doing the same.

engine-setup already supports firewalld, which does a better job in letting other tools to rather-cleanly manipulate its rules.
This works well on fedora, and hopefully soon on rhel7. It's not perfect, but way better than /etc/sysconfig/iptables.

Closing. Please reopen if relevant, with clear details about what to solve and how.