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

[David Woodhouse]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140428/c4d2b285/attachment.bin>