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

[Simo Sorce]

On Wed, 2014-03-05 at 15:35 +0100, Miloslav Trmač wrote:
> 2014-03-04 21:31 GMT+01:00 Simo Sorce <simo at redhat.com>:
> 
> > On Tue, 2014-03-04 at 14:07 +0100, Miloslav Trmač wrote:
> > > I see having a firewall running by default, but punching holes in it
> > > by default, without explicit user involvement, as such a case: the
> > > underlying reason to have a firewall seems to be defeated by the way
> > > the firewall is being used.
> >
> > Here lies the error of your reasoning.
> >
> > Roles do not do anything without *explicit user involvement*.
> > You actually have to install *and* setup a role on your system to poke
> > any hole.
> >
> 
> OK, so let's clarify how explicit the involvement is.  When the user runs
> (fedora-role-deploy $rolename), will this
> 
>    - Always punch a hole in the firewall, because the "fedora-role-deploy"
>    was an explicit action?
>    - Ask the user, and acting on the answer, which was an explicit action?
>    - Not ask the user, but do what the role thinks is appropriate, because
>    deploying a role was an explicit action?

One of the three depending on the Role, they are all on the table,
because different roles have different properties and defaults.

> My primary objection is to the latest option: If the user can't predict the
> effect of their command, I don't think the command was an "explicit" user
> action.  It's just unpredictable unless you read all documentation, which
> many people don't.

I do not understand what you mean. If you deploy a domain controller do
you expect it to be in full working condition when you are done
configuring it through the role deploy command ?
I do very much expect so, and to fullfill that expectation the role
deployment script needs to open the appropriate KRB/LDAP/etc.. ports or
the role is simply non-functional.

Why wouldn't the admin expect that ?

Note that we currently do not do that in the ipa-server-install script
because we didn't have a simple API to call in the past and it is one of
the rough edges, so much so that when the script ends we have to print a
long blurb to tell the admin he has to open all these ports. That sucks,
and very often it happens admins simply turn off the firewall instead of
poking only the necessary holes as result.

> And not poking holes for some roles makes no sense, because the role can
> > only be used (in the common case) if it is reachable from the network,
> > and if it is unreachable it does not work.
> >
> Yes.
> 
> One of the assumptions for roles is that we want to have them working as
> > intended once the setup is complete.
> >
> Yes.
> 
> For example I think the best default for the domain controller role will
> > be to open the firewall, while the best default for the database role
> > will be to keep it closed.
> >
> That may be *individually* true, but the user gets differing behavior
> without having clearly acknowledged or caused such a difference, put
> together into a single product doesn't give the user sufficient visibility.

I do not understand your point here. Different roles have different
characteristics. Roles that do not open ports by default can warn the
user that they did not do so and tell them what is the role-command to
use to open the default ports for the role.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York