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

[Stephen John Smoogen]

On 20 March 2014 11:34, Lennart Poettering <mzerqung at 0pointer.de> wrote:

> Heya!
>
> I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
> Fedora. There has been a request in systemd upstream to disable support
> for it by default, but I am not sure I want to do that unless we can
> maybe say goodbye to it for the big picture too.
>
> Why would we get rid of them?
>
> Well, to make things simpler, primarily. They have not seen any
> development since 2003 (that's 11 years I mind you, an eternity in IT).
>
> I doubt there are many people even using them anymore, firewalls are
> more comprehensive and a lot more powerful, and while every admin knows
> firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
> actively make use of them...
>
>
Actually they are used quite a bit in various service worlds. Mainly for
ssh and email for dealing with scanners. [DenyHosts is a boon in this
area.] The reason for using a secondary tool is that depth of security.
Over the years I have found that there are multiple of attacks which will
nullify one layer of protection at one point or another. Having a second
level or third level of protection is a boon when this happens.

At the enterprise level firewalls can come under a different set of change
control rules than something like tcpwrappers which is considered
application level. While I would like to be able to make a simple change in
a firewall, I can end up spending a month until I can. Application controls
are usually an hour or so signoff. This means that if tcp-wrappers is going
then something will need to be able to replace it to meet that large scale
concern. [Automatic firewall controls like firewalld have to be disabled or
put into a manual changes only mode in these areas for change control
purposes. ]

I can't argue on the code maintainability or layout. Not my area of
expertise. I can say that if tcpd/libtcpwrappers were to go away that
something equivalent would need to be built to replace it for the ability
to fine tune at a layer below the firewall.




> The API is awful, too, with lot's of open-coded structures, feature
> checks in the headers, fixed length strings, globally exported variables,
> non-namespaced symbols, really weird exported compatibility wrappers for
> OS calls...
>
> I'd propose we make a clear cut, and just start disabling it in all
> services that link to it, instead of letting rot on in Fedora for all
> eternity.
>
> It's bad code, little used, crufty. We have much better stuff now, and
> that enables us to say goodbye to the old mess...
>
> I figure there will be a bit of opposition to this change, thus I
> thought I start the discussion on the fedora ML first. Unless there are
> major concerns I will propose a feature about this in the next few
> days. If somebody wants to join me on this and put his name on the
> feature proposal I'd be delighted!
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140320/e90de9ca/attachment.html>