Maybe it's time to get rid of tcpwrappers/tcpd?

"Jóhann B. Guðmundsson" johannbg at gmail.com
Sat Mar 22 10:04:51 UTC 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140322/b5c990ef/attachment.html>


More information about the devel mailing list