On 03/22/2014 04:20 AM, Miloslav Trmač wrote:
I'm not in this thread to discuss technical merits of the existing
implementation. It may be 100% crappy code. /All/ of what you say
above may be true, but that being true about a widely-used feature
/doesn't automatically mean that eliminating the feature increases
securit/y.
I'm not even in this thread to object to doing extra work to break
users' systems, because you may be right that most users of
tcp_wrappers that use it for the DNS functionality shouldn't, and it
might be irresponsible for us to support such configurations.
I'm participating in this discussion because, as a general rule, I
assume most administrators configuring security, and most users in
general, /aren't idiots/. So, the fairly large number of assumed
non-idiots using this functionality suggests, as a first approximation
to truth, that it is useful, and it's the few of us that discuss
removal of the feature that are wrong about the consequences of our
actions.
So here's the thing daemons and applications are inconsistent in their
support for libwrap like for example sshd supports it while smbd does
not which leads to incorrect configuration and administrative
expectation which in itself poses a security risk.
The only way administrator can figure out which daemon/service was built
with libwrap support, is via ldd/string grep magic since we as an
distribution have not provide them with a list which do support it and
which do not,nor do we have those component correctly depend on
libwrap.so.0.
The undisputed fact is you are truly better off security and performance
wize using netfilter to solve this which can be done via tcp-wrapper
like behavior so...
iptables -A INPUT -p tcp --dport <port> -m iprange --src-range
<ip-range>-<iprange> -j ACCEPT
iptables -A INPUT -p tcp --dport <port> -j DROP
We should have dropped tcp-wrappers as well as denyhosts etc. a long
time ago but you know old habits die hard and all that but if FESCo is
going to refuse to do that it should ensure at least there will be a
list which explains it to adminstrators which component support this and
proper package dependency on libwrab for administrators sanity and
expectations...
JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
