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
also disadvantages:
+ 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
static.
- 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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
