[Freeipa-devel] Ipa-server-install Firewall Support

Justin Brown justin.brown at fandingo.org
Wed Apr 16 07:56:08 UTC 2014 

Dmitri,

Thanks for the feedback. I've had a chance to revise the proposal and
incorporated your feedback. The first thing to note is that while this
implementation is focused on FirewallD support I want to leave open
the possibility of supporting other firewalls should anyone else be
interested writing the patches. To that end, the module name and
command option says "firewall" not FirewallD. Therefore, I've moved
the proposal page to
http://www.freeipa.org/page/V4/Firewall_Configuration.

I've addressed most of your questions, but here's a brief overview:

A, B, C, and D: Corrected

E: There's a "DBus Method Overview" section now.

F: I added a statement about error handling. It's hard to go into too
much detail about how the various failures will be handled on the
wiki. Error handling is very important to me, so don't worry that I'm
overlooking it.

G: It's really easy to handle existing configurations with FirewallD.
(It's actually what makes this possible in comparison to iptables-save
scripts.) There will be log messages to notify the user that some
services were already allowed to caution that they should not be
removed.

H and I: There's a "restore" sub-section in the wiki. This will be
easy to handle since the zone uses easily parsable XML.

J: Yes. When ipa-server-install invokes the firewall module, it passes
through a list of which services should be enabled.

K: This will be easy for the firewall configuration module. Just
invoke it with the new services. Is there an upgrade script currently,
and if so, where is it? I'll add in the proper section there for the
firewall.

L: This is interesting, and I have a couple of questions on how this
should work.

1) Is there an actual use-case when a tool actually would want to
check status of a port without correcting it? It seems to me that any
sort of is_port_open() call that returned False would be immediately
followed by open_port(). If that's the case, then why not just roll
them into one operation? There won't be any firewall reload if no
modifications take place, so there's no cost to combining them. We
could also find a middle ground where there's only one method with a
default parameter open_port(..., auto_add=True).

2) Will these tools be executed as root? To query NM and FirewallD, I
have to connect to the system bus, which by default, won't allow
access from other users without additional authorization. If
non-privileged users need to query the firewall configuration, I'll
need to look at the DBus policy more closely.

3) Could you point me at a similar tool that has this check and modify
behavior?

Thanks,
Justin

On Wed, Apr 9, 2014 at 7:57 PM, Dmitri Pal <dpal at redhat.com> wrote:
> On 04/08/2014 02:42 PM, Rob Crittenden wrote:
>>
>> Justin Brown wrote:
>>>
>>> Dmitri,
>>>
>>> I'd be more than happy to, but I'm having trouble figuring out where
>>> it should go. Could you send me a link to a similar design page?
>>>
>>
>> I'd put it under here: http://www.freeipa.org/page/V4_Proposals
>>
>> There is a template at http://www.freeipa.org/page/Feature_template
>>
>> So maybe something like http://www.freeipa.org/page/V4/Firewalld
>
>
>
> Rob has beaten me to it, sorry.
> I reviewed the page.
> Pretty informative, thank you.
>
> Couple comments:
> a) No replication impact.
> b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2
> --forwarder=192.168.0.3
> I think you want to add the --firewall at the end
> c) Please be consistent in one place you use freeipa-.. in other just ipa-..
> but this is minor
> d) No commands or config options.
> e) It would be really nice to have a bit more information about what kind of
> methods and calls you plan to use to interact with NetworkManager and
> FirewallD. If you can spell out something like:
> Logic:
> Call NM and get blah using method X
> For each port in the list
>  call FirewallD method Y
> f) What would be error handling if something goes wrong? Would it abort or
> create a special message?
> g) How should it behave if some ports are already open? Will it print a
> message or do it silently?
> h) There is actually impact on restore, restore might also now check that
> ports are configured in the same way they have been.
> i) We should probably also record in the rollback log the ports that have
> been opened and close them back if we have to roll back installation  or
> uninstall server.
> j) We should differentiate whether the CA is being installed and open CA
> ports only if the CA component is there.
> k) We are planning to add other components like DRM and TPS We need to
> figure out if we would have to do something on the upgades when we add those
> services to add additional ports.
> l) I suspect that there be cases where different tools and scripts in IPA
> would need to check and open ports. This means that we should probably
> create a reusble library that would provide check and update methods.
>
>
> This is so far what came to mind.
> Thanks for doing it!
> Really appreciated.
>
>
> Dmitri
>
>>
>> rob
>>
>>> Thanks,
>>> Justin
>>>
>>> On Mon, Apr 7, 2014 at 6:51 PM, Dmitri Pal <dpal at redhat.com> wrote:
>>>>
>>>> On 04/07/2014 09:00 AM, Rob Crittenden wrote:
>>>>>
>>>>>
>>>>> Simo Sorce wrote:
>>>>>>
>>>>>>
>>>>>> On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 4.4.2014 09:17, Martin Kosek wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/04/2014 09:04 AM, Justin Brown wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I would actually do it the opposite way and open the ports after
>>>>>>>>>> the
>>>>>>>>>> FreeIPA server is fully configured. After all, I do not think we
>>>>>>>>>> want to
>>>>>>>>>> open the ports when the server is just half-configured and for
>>>>>>>>>> example some
>>>>>>>>>> ACIs are missing.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My thinking was that nothing would be listening on these ports if
>>>>>>>>> the
>>>>>>>>> install doesn't succeed, but there's really necessity to modify the
>>>>>>>>> firewall configuration early. (All of the internal install
>>>>>>>>> communication will be over a local interface (to netfilter) and
>>>>>>>>> unblock anyways. I don't have any problem in delaying firewall
>>>>>>>>> configuration to the end of install.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If ipa-server-install does succeed without configuring the
>>>>>>>> firewalld,
>>>>>>>> then we
>>>>>>>> will indeed have no other option than to do it early.
>>>>>>>>
>>>>>>>> I am  thinking that we may want to put all the firewalld
>>>>>>>> configuration
>>>>>>>> in
>>>>>>>> ipaserver/install/firewalldinstance.py,
>>>>>>>> and then make the firewalld configuration the actual step of the
>>>>>>>> installation.
>>>>>>>> Something like:
>>>>>>>>
>>>>>>>> ...
>>>>>>>> Configuring Firewall (firewalld)
>>>>>>>>      [1/2]: looking up the right zone
>>>>>>>>      [2/2]: allowing ports
>>>>>>>> Done configuring Firewall (firewalld).
>>>>>>>> ...
>>>>>>>>
>>>>>>>> The Service class derived object can be really simple, we would just
>>>>>>>> reuse the
>>>>>>>> functionality it already has + let us properly hook into it in
>>>>>>>> ipa-{server,replica}-install and the uninstallation.
>>>>>>>>
>>>>>>>> It would also make it easier to split this functionality to
>>>>>>>> freeipa-server-firewalld if we chose to in a future.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In general I agree with the idea, thank you Justin for working on
>>>>>>> that!
>>>>>>>
>>>>>>> I would like to emphasis the necessity to work without NetworkManager
>>>>>>> and
>>>>>>> FirewallD. New dependencies make Debian folks unhappy ...
>>>>>>>
>>>>>>> On the other hand, it is perfectly fine to skip firewall
>>>>>>> configuration
>>>>>>> if
>>>>>>> NM/FirewallD/DBus is not available.
>>>>>>>
>>>>>>> Have a nice day!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Should be easy, probe for the dbus firewalld service and just skip
>>>>>> (not
>>>>>> error out) if it is not there.
>>>>>> Set a variable in that case that will cause the installer to throw the
>>>>>> classic banner we have now which warns you about what ports need to be
>>>>>> opened at the end of the install.
>>>>>
>>>>>
>>>>>
>>>>> Probably just need to spit out a large, preferably flashing warning
>>>>> that
>>>>> the firewall has not been automatically configured. Perhaps even
>>>>> multiple
>>>>> times: one in-line and one at the install summary at the end.
>>>>>
>>>>> rob
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-devel mailing list
>>>>> Freeipa-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>>
>>>>
>>>>
>>>> Thanks for looking into this!
>>>>
>>>> Would it be possible to summarize this thread in a design page on the
>>>> wiki?
>>>>
>>>> --
>>>> Thank you,
>>>> Dmitri Pal
>>>>
>>>> Sr. Engineering Manager IdM portfolio
>>>> Red Hat, Inc.
>>>>
>>>>
>>>> _______________________________________________
>>>> Freeipa-devel mailing list
>>>> Freeipa-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>
>>>
>>> _______________________________________________
>>> Freeipa-devel mailing list
>>> Freeipa-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>
>>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IdM portfolio
> Red Hat, Inc.
>

More information about the Freeipa-devel mailing list