Kevin Fenzi wrote:
Please have a look at custom rules in system-config-firewall. It already has the ability to add custom rules.On Sun, 14 Jun 2009 18:34:52 +0100 Matthew Garrett <mjg redhat com> wrote:On Sun, Jun 14, 2009 at 06:13:51PM +0200, Julian Aloofi wrote:So, solving this is pretty easy, even for newbies. But I agree that the error message will not help someone without advanced knowledge. Although I think people running Samba generally will know where to look for the problem.I think this is actually a problem that needs solving. We have several network services that are either installed by default or might be expected to be part of a standard setup, but which don't work because of the default firewall rules. The Anaconda people have (sensibly, IMHO) refused to simply add further exceptions to the firewall policy.So, what should happen here? Should we leave the firewall enabled in these cases* by default and require admins to open them? If so, isthere any way that we can make this easier in some Packagekit-oriented manner? If not, how should we define that packages indicate that they need ports opened? Should this be handled at install time or run time?* The case that I keep hitting is mDNS resolution, which requires opening a hole in the firewallI keep wondering if we couldn't come up with something like a /etc/iptables.d/ type setup somehow that would work for thesecases.In the case of a package that does not need any configuration done and only needs a firewall rule to function, we could add a file in there toadd it's rule.For cases of packages that DO need to be configured, add a file, but have it disabled/commented until the service is configured. This could be done by hand, or when someone runs a system-config-whatever and finishes configuring, the rules could be enabled by the tool as part ofa 'make live' or 'activate' or something.If we had something like this, packages could ship theirown /etc/iptables.d files.
The major problem with a /etc/iptables.d direcory with files provided by packages are that you can not say in the end what your firewall will look like: Is the firewall is open for a specific service/host/network or not. The files are text blobs and therefore there is no way to say what they will do. The only thing you could do is to read the files or the iptables service status output after applying the new firewall rules. This might be hard to understand for most people and also may be too late. Please think of a scenario like this: Service A is adding firewall rules for opening port 20 and 21 (ftp-data and ftp) for everyone and service B is opening port 20 and 21 only for a specific network segment. What do you want to have here? If you apply A's rules first then 20 and 21 is open for everyone and the rules from B are not used at all. But if you apply B's rules first, ... What is the right ordering here? Should A or B win?
If you have packages dropping in some firewall rules into the firewall without the ability for activation/deactivation and also sorting of the rules, then you could get into unexpected behaviour and also big security risks.
To make custom rules a little bit more transparent, the feature has been added to system-config-firewall and lokkit to add custom rules by type and table, where type is ipv4 or ipv6 and table is mangle, nat or filter. The admin can add and remove files from the custom rules list and also has the ability to change the order. But I think that using custom rules for every service will be a big problem for users, because they do not know what the result of using custom rules will be.
A big problem with custom rules is: What are the rules made for: A server with trusted networks, a workstation or a notebook used in an internet cafe or even other environments? All these do need other configurations. Therefore it is needed to have the ability to define the type of a network connection or network segements: Is it to be trusted or untrusted?
Another questions is: Should a custom rule be able to override standard rules?
Just a thought.Making firewalling and firewall configuration suitable for everyone is a hard thing and the question is if this is possible at all.kevin