firewalld vs iptables vs ? as default (was Comparison to Workstation Technical Specification)

Thu Mar 6 21:43:14 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/2014 04:28 PM, Reindl Harald wrote:
> 
> 
> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo at redhat.com
>> <mailto:simo at redhat.com>>: Sorry I do not understand what you are
>> saying here.
>> 
>> $ fedora-role-deploy postgresql # Huh, it is refusing
>> connections? # Ah, firewall... $ fedora-role-deploy
>> --open-firewall-ports potgresql # That's how it is done in
>> Fedora, then.  Good to know.
> 
> right direction
> 
>> # Time passes...
>> 
>> $ fedora-role-deploy freeipa # Huh, this is already accessible?
> 
> that must not happen
> 
> * not from usability point of view * not from security point of
> view - *no* open ports *never ever* as default
> 

The debate here is where you draw the line as to "what is default".
Deploying a role is *NOT* the same as just installing a package. For
package installs, I absolutely agree that we should never be poking
holes in the firewall.

I can see Simo's point about the expectation that when you tell a
machine "You're a domain controller now!" that it's awkward for it not
to immediately be available, while the same is not necessarily true of
a database (which might only want local access).

So I have no problems at all with Miloslav's suggestion that we just
require an additional argument (which will have to be translated to
the API layer in a sensible way) as part of the configuration.

It probably does hit that fine line between usable and secure
reasonably well.

Of course, the question becomes one of granularity: I doubt that
- --open-firewall-ports is necessarily sufficient. In the case of
multi-homed servers, you still may want to have the service visible
only on a subset of interfaces. I'd suggest
- --open-firewall-ports[=iface1,...] as a reasonable compromise (and
again translated acceptably into the Role config API).

And finally, the config API must also be capable of changing the set
of open interfaces (such as when local testing has passed and the
admin now wants to expose the services publicly).