an that is why we need a firewall -> Re: When a yum update sets up an MTA ...

[Miloslav Trmač]

2014-04-28 12:42 GMT+02:00 David Woodhouse <dwmw2 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140428/2d5fc092/attachment.html>