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

[Martin Kosek]

On 04/03/2014 06:33 PM, Justin Brown wrote:
> This discussion morphs out of some questions that I asked over on the
> user's mailing list:
> https://www.redhat.com/archives/freeipa-users/2014-April/msg00033.html.
> It's also related to Trac #2110. (The subject says ipa-server-install,
> but this will also apply to replica installs, too.)
> 
> What is the expected compatibility with RHEL 5 and 6? Neither of those
> comes with FirewallD. Integrating with iptables is bound to be messy,
> and I feel like there's too many ways to get into trouble with
> destroying a user's iptables configuration. (Due to the unsafety of
> `iptables-restore`, there's no way to guarantee that the user's
> configuration will persist through a reboot.) Seeing as FirewallD has
> been the default in Fedora since 18 and will be in RHEL 7, it seems
> like a reasonable thing to do. Would there be opposition to making
> FirewallD the only firewall that ipa-server-install will configure,
> and just print out iptables (or iptables-save fragments) for
> non-FirewallD systems?

Right. I do not think there will be opposition for firewalld. As you said, it
is present in recent Fedoras and RHEL-7.0 and we do not plan to release FreeIPA
4.0 in older systems than that.


> The implementation should be pretty simple and straightforward, but I
> wanted to run over it briefly to see if there were any initial
> feedback.

+1.

> First, there's a question of dependence. FirewallD exposes a DBus
> interface on the system bus. While it is possible to interact with
> shell commands, I would greatly prefer to make use of DBus directly.
> That will require pulling in python-dbus as a package dependency.

I personally have nothing against using python-dbus interface (dbus-python
package in Fedora), it is programmatically easier to control that parsing
output from commands.

> 
> Second, FirewallD operates on "zones" to which interfaces are
> attached. To apply any sort of configuration, we'll need to attach a
> freeipa-server FirewallD service to the proper zone. During the
> current installation program, we already know the server's IP address
> from a call to installutils.get_server_ip_address(). I'll need to
> resolve on which interface this IP resides, and then FirewallD can
> tell me which zone should be modified. It is possible to scrape the
> output of `ip address` to determine, but that's a messy solution. The
> better method is to use the NetworkManager DBus interfaces to query
> for this information. This gets back to my compatibility question
> above. Fedora doesn't really work without NetworkManager anymore, and
> I assume that will hold for RHEL 7.

Right, I personally do not see a problem here in your thoughts.

> Third, do we want to allow the user to limit the network access? I
> think that it makes sense to allow users to specify a network (e.g.
> 192.168.0.0/16) to limit accessibility to their FreeIPA server. Yet,
> there's always some trade-off to adding more options to
> ipa-server-install.

Hm, I would personally prefer to avoid complicating the feature and start with
something easy to configure and straightforward. We can always extend it if wee
see an interest. In general, ipa-server-install does the basic, functional and
recommended configuration - fine tuning is left for the administrator to
continue after that. But I will leave that up to you and other developers.

> Fourth, FirewallD configuration is simple and quick, so I think it
> makes sense to get it out of the way early in the install process. I'm
> thinking right after ipaservices.backup_and_replace_hostname() (line
> 1,038) runs.

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.

> 
> 
> Implementation Walkthrough
> ----------------------------------------
> 
> ~$ ipa-server-install --firewall --firewall-allow 192.168.0.0/24
> --firewall-allow 192.168.1.0/24 [...]
> [skip to line 1038]
> 1. Detect if FirewallD is running via DBus. (If not generate sample
> iptables rules, print/log them, and continue normal install.)

We print list of ports that FreeIPA uses at the end of ipa-server-install
process. I would report firewalld/iptables related information there. (We for
example also create here example BIND zone content and pass it to user, it may
make sense to have this around this location).

On the beginning of the installation (in the interactive part of
ipa-server-install) I would just check if firewalld is available and if not, I
would print a warning to user so that he can for example exit the wizard and
fix firewalld  before continuing.

> 2. Use NM DBus to resolve IP->interface. (If NM not available,
> potentially fallback to scrapping `ip a`.)
> 3. Use FirewallD DBus to resolve interface to zone.
> 4. FreeIPA will include a service XML template (like
> dsinstance.INF_TEMPLATE) that specifies the necessary ports/protocols.
> Write this service file to /etc/firewalld/services/.

Ok. We also should not crash if the directory is not available. There are some
recommendations about the XML contents in a Bugzilla comment:

https://bugzilla.redhat.com/show_bug.cgi?id=885483#c2

I think it would be better to have them all in a single XML file though (like
freeipa.xml), less chance of name collisions and we would have all ports in one
place.

Not sure about the names, but it may be good idea to prefix the port names with
"freeipa", i.e. "freeipa-ldap", "freeipa-ldaps", "freeipa-kerberos" to avoid
collisions.


> 5. If the user provided --firewall-allow args, generate rich rules
> based on the template, and add them to the proper zone. If not, the
> service is still added as a rich rule (for consistency and ease of
> uninstall).

Ok.

> 
> 
> Thanks,
> Justin

I think you are on a good path Justin, good luck!

Martin