Kevin Fenzi wrote:
On Sun, 14 Jun 2009 18:34:52 +0100
Matthew Garrett <mjg@xxxxxxxxxx> 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, is
there 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 firewall
I keep wondering if we couldn't come up with something
like a /etc/iptables.d/ type setup somehow that would work for these
cases.
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 to
add 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 of
a 'make live' or 'activate' or something.
If we had something like this, packages could ship their
own /etc/iptables.d files.
Please have a look at custom rules in system-config-firewall. It already
has the ability to add custom rules.
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.
kevin
Making firewalling and firewall configuration suitable for everyone is a
hard thing and the question is if this is possible at all.
Thomas
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
