an that is why we need a firewall -> Re: When a yum update sets up an MTA ...
twoerner at redhat.com
Tue Apr 29 10:37:13 UTC 2014
On 04/28/2014 08:09 PM, Florian Weimer wrote:
> On 04/28/2014 12:42 PM, David Woodhouse wrote:
>> 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.
> Can we make this stick for the unconfined_t user as well? How can
> system administrators configure exceptions? What about developers who
> need to bind to various ports, e.g. while running test suites? Will it
> be as straightforward as with firewalld?
> An explicit failure on bind() might actually give us better error
> reporting (especially if the EPERM details idea is implemented). I like
> the SELinux idea.
To be able to bind only in a "trusted" environment has advantages, but
+ You have the possibility of error reporting if the app is designed in
the way to fail gracefully in the "unable to open port" case.
- Only works in a simple network environment that needs to be at best
- Does not work with more than one active connection where some are
"trusted" and others are not without adding mechanisms in all network
services and apps that will take care about this internally with
configuration and policies.
- Is not working while switching the network environment from "trusted"
to "untrusted" or vice versa without having network services and apps
that will react gracefully on a now closed port or that are able to bind
later on to. Rebooting the system, restarting all network services and
apps or logging out and back in is not a good solution for this.
Ergo: You need to have very smart network services and apps with this.
More information about the devel