On Mon, 2014-04-21 at 09:42 +0200, Reindl Harald wrote: > > Am 21.04.2014 03:39, schrieb Lars Seipel: > > Nicely aligning with the current firewall thread I noticed that one of > > my machines was running the exim MTA for the last few days, dutifully > > listening on all interfaces > > and now it is *proven for sure* that disable the firewall > by default is the most dumb thing a distribution can do This doesn't make much sense to me. Take a look at the wording of the proposed change: "The current level of integration into the desktop and applications does not justify enabling the firewalld service by default." Now imagine the situation if we take the opposite approach — we *fix* the integration, and leave it enabled by default. Fixing the integration means that installing packages which need to listen on a network socket should Just Work™. That means they'll talk to firewalld somehow, to enable their ports. We need that, because from a usability point of view it just isn't acceptable to have things which *appear* to work when you test them from localhost, but silently fail when you connect from the outside. That's a really insidious failure mode which has bitten me a number of times when I've forgotten to turn off the misguided firewall on a newly-installed machine. So when it's all finished and working properly, the firewall doesn't really buy you anything in this case. A package which is set up to listen by default will still do that, and it'll still be a bug in the package in question. Actually, I think the best way to fix this is with SELinux, rather than iptables. Why go for an overly complex solution where authorised processes have to prod a firewall dæmon to change the iptables configuration, when the kernel has a perfectly good "firewall" built in as a fundamental part of the IP stack? Send a TCP SYN to a port which nobody's listening on, and you'll get a TCP RST back. Send a UDP packet to closed port, and you'll get an ICMP 'port unreachable' back. No need for iptables at all. All you need to do, if you really want to control incoming connections, is use SELinux to limit who can bind() and listen() to certain ports. And that approach has the advantage that you can make sure it's the *right* program listening. You can make sure that only the MTA is listening on port 25 and not anything else, for example. Perhaps we'd end up with an SELinux boolean which enables incoming connections on port 25 — which could be disabled by default and which *would* protect you from packages listening by default when we really didn't want them to. And the failure mode would be clear and simple, as the listen() call fails and the dæmon would *know* that it's not working. The reporting for that is already hooked up to the user interface, and it would be really simple for the user/admin to use 'setsebool' to enable it when necessary. We'd stick a comment to that effect in the default config file by the 'local_interfaces' option, of course. -- dwmw2
<<attachment: smime.p7s>>
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
