Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1054296 - [RFE] RHEVM should use its own iptables (whatever other FW is) chain
Summary: [RFE] RHEVM should use its own iptables (whatever other FW is) chain
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Yedidyah Bar David
QA Contact: Pavel Stehlik
URL:
Whiteboard: integration
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-16 15:02 UTC by Jiri Belka
Modified: 2014-08-05 11:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-05 11:07:35 UTC
oVirt Team: ---
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.