-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lukas Ocilka wrote:
Actually, yast2-firewall has been proposed to be used by common users. With some [Advanced] configuration for advanced users (or Server settings).
Xinetd configuration is a bit different and it's not suitable for common users. From my point of view, it's one badly-arranged table of settings.
Firewall configuration is set of more features divided into smaller dialogs. Considering the fact, that firewall plays with the security of the system, it should be as simple as possible and there should be listed as few entries as possible. That's why the firewall has also the Summary screen before saving the configuration.
Right, and what would help is:
- - only list services/ports for servers (and sometimes clients) that are
actually installed, because the service/port definitions are provided by
RPMs (e.g. no HTTP/HTTPS if apache2 is not installed)
- - provide a description of the service/ports you would open up
Now that the idea has sparked some fire... I can see a few spots that
should be thought of, as potential issues.
Let's fuel some thoughts to it ;)
1) Conflicts
============
How to handle if, say, I have both apache2 and lighttpd installed at the
same time ?
Of course, the user will have to change listen ports anyway, because
both HTTP daemons would conflict for system resources in the first place.
But, say, I put apache on 80 and 443, and lighttpd on 8080.
To me, that means a few things:
The definition files in /etc/sysconfig/SuSEfirewall2.d/ (or wherever)
must be named after the *package*, not the service.
For the example above, we'd have, in that directory:
apache2.xml
lighttpd.xml
Also, we might need "port groups", because one package could
listen/require several ports or port ranges, that can be turned on or
off individually.
For apache2, that would be HTTP (80) and HTTPS (443).
For tomcat, that would be 8080, 8081 and the various control ports.
The apache2.xml file could look something like this:
- ---8<------------------------------------------------------------
<susefirewall2-service id="apache">
<summary lang="en">Web server</summary>
<summary lang="fr">Serveur Web</summary>
<description lang="en">
Authorize access to websites hosted on this server,
through Apache2.
</description>
...
<port-group id="http">
<port proto="tcp" port="80" />
<description lang="en">
Authorize access to the standard, non-encrypted HTTP port.
</description>
</port-group>
<port-group id="https">
<port proto="tcp" port="443" />
<description lang="en">
Authorize access to the encrypted and secure HTTPS port.
</description>
</port-group>
</susefirewall2-service>
- ---8<------------------------------------------------------------
So, how to handle conflicts ?
I think it should be done in the UI: if the end-user enables both 80 for
apache and then tries to enable 80 for lighttpd, the UI should refuse to
do so and provide an informative message on why that is not possible.
Or it could just pop up a warning/information message that the port 80
is already open for apache2, because for SuSEfirewall2, in the end, it
just means: ALLOW on TCP port 80, whatever the daemon is.
But then one must be careful when the end-user chooses to close down
"HTTP for Apache2", because it might still end up being open because he
has also enabled "HTTP for lighttpd".
So.. it's not *that* easy ;)
2) Port changes
===============
A more experienced user might want to change the port some service is
listening on.
As of the example above, he could change the lighttpd configuration to
listen on 8080 instead of 80.
The problem is that the lighttpd.xml file for the firewall is static,
and hence still contains "80" instead of "8080" for the TCP port.
The only option I see atm would be to also ship some scripts that
validate the firewall config files (e.g. lighttpd.xml) against the
configuration of the daemon.
That must also be provided by the package, because each piece of
software uses different formats and tags for configuration.
This is when it becomes a bit tricky.
A less perfect but simpler, and hence better option could also be to
give the admin the possibility of overriding the ports for a given
"service" (e.g. lighttpd or apache2) in the firewall config UI.
There are too many cases you couldn't catch with the first approach (use
an alternative config file, or just think of the apache2 config: it's so
versatile and complex that the port that is actually used could be
hidden almost anywhere (in vhosts.d/* or a conf.d/*)).
So maybe it's just better to let the more experienced user handle that
himself.
3) Extensible (by the user/admin)
=================================
Similar to above, consider apache2: if someone adds several vhosts that
listen on different ports (e.g. 8080, 10000, 11000)...
So there must still be some option to add ports yourself.
It would be even nicer if they could be associated with the "apache2"
config for the firewall. That way, in the firewall config screen, the
admin could just say: disable apache2 (and all the ports that are
associated with it, including for his own vhosts).
Maybe a collapsable tree-like UI would be appropriate:
[-] lighttpd (summary, description)
[ ] HTTP (80)
[ ] HTTPS (443)
[x] 8080 (added by user)
[x] apache2 (summary, descr.)
[x] HTTP (80)
[x] HTTPS (443)
[x] 10000 (added by user)
[ ] jabberd (summary, descr)
[ ] XMPP (5222)
[ ] XMPP/SSL (5223)
etc...
That's probably easy enough for beginners and still flexible enough for
experts.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\