2014-04-28 12:42 GMT+02:00 David Woodhouse <dw...@infradead.org>:
> 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.
>
No no no no no. If you want a firewall "integrated" *that* way, you are
really better of uninstalling it or opening it up; it serves no purpose.
(Which is why I think opening up the firewall on Workstation might have
been the right thing to do; it was the other parts of the proposal to the
effect of "we'll make it secure later" that were a non-starter.)
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?
More generally, an application- instead of port-based firewall
configuration might be interesting (aside from protecting "ownership" of
some well-known ports I suppose). But that needs having a
security-relevant *concept* of an application, something we don't have on
the desktop with everything running as unconfined_t and ptrace() allowed,
and something we... sort of have but not enough, with PHP scripts running
in-process in the same domain as the main http server.
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
