-----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/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEpPrEr3NMWliFcXcRAuCCAJ9RWVdye3d2PelRp/PzVa97V+Q0+wCgiGAM iSofHvJdpeiAK4rE5e5S0Uc= =SAqi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org