On 20 March 2014 13:05, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote:
On Thu, 20.03.14 12:20, Stephen John Smoogen (smooge@xxxxxxxxx) wrote:Well, all mails servers as well as sshd have much better ways to do
> > 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.
such filtering. sshd has "Match", Postfix for example has
"smtpd_client_restrictions=", and so on.
And now I need to have X number applications special syntax to whitelist/blacklist a site. I need to change X files to make that change. Each of those could be a separate change control process depending on the size of the organization. Or I have 1 file that I can make a change to which has usually one syntax and one set of reviews.
Again, I have no doubt that some people still use tcpwrappers. But I'd
argue that is clearly the excpetion, not the rule, and they'd better use
something different, and that we should be creating an excellent distro,
instead of a one that features horrible software...
Look I am not saying it isn't horrible to look at from a coding side. From a systems administrators side it does stuff in a very clean, easily audited way. It is also a nice key place where every application is actually using the same syntax versus each custom version. Having spent several ITIL meetings where you have to explain the syntax of each application to non-sysadmins, then prove that the change is correct, then prove that the change is easily backed out, and then other parts.. having 1 syntax to do that versus doing every applications custom version makes it a lot easier to deal with.
I am not saying rip it out, but I am saying that you need something that replaces that one syntax, one file control, simple syntax method.
> Over the years I have found that there are multiple of attacks which willWell, it certainly makes sense to combine a firewall with let's say
> 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.
selinux with maybe postfix/ssh acls. Then you already have three layers
of protection, of very good protection. But of all possible options
tcpwrap is the absolute worst choice. And we should be able to deprecate
and remove stuff from our core OS if we think it is crap.
I mean, there are two sides of the medal: sure multiple layers of
protection might be a good thing, but you also make things a lot more
complex with each one, and you involve more possibly exploitable code --
and tcpwrap is simply bad code, that's a fact. So you have to balance
things out: is something a layer that is worth the trouble? Or does
having it around make things worse? I am of the opinion that tcpwrap
indeed does make things worse.
Sure, three layers of condoms probably make sex safer, but then again,
if one of them is made of 10 year old half-decomposed goat intestines,
then maybe the sex is a lot less fun, too...
I don't see the need to make such crude references.
> At the enterprise level firewalls can come under a different set of changeWell, that really sounds like a specific issue of your
> 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. ]
company... Really, I don't think the question whether the bureaucracy of
some hypothetical company makes a distinction between tcwrap and
firewalls has no place in the discussion whether we should support
tcpwrap in our distro or not.
I am giving you a standard enterprise problem. You are constantly going on about how systemd solves enterprise level problems and enterprises will love them. I am giving you a standard problem that tcpwrappers solves and you need to come up with some sort of replacement for them. Most real problems enterprise administrators deal with are people oriented and this is a tool which deals with those problems in a way that is clean and clear.
All I am trying to do is point them out to you so that you don't end up having to spend all of 2016 recoding a replacement because it became a deal breaker for the various enterprise downstreams. If you want to make this a "You dare question me?" then fine, I can go do something else and know in the future that you aren't really looking for feedback.
> I can't argue on the code maintainability or layout. Not my area ofWhy? Other than your hypothetical bureaucracy, is there anything that
> 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.
tcpwrap can do that firewalls can't do, that really deserves to be
supported? I really can't see anything... [1]
I never rely on dns in hosts.allow or .deny. I use just ip addresses. So I don't see what [0] has on this.
tcpd comes from a time when there weren't local firewalls available in
all Unix systems, so they built something like them in userspace. But
that time is long long gone, and pretty much any Linux installation I
know nowadays has a firewall compiled into the kernel...
Lennart
[1] well, sure tcpwrap resolves DNS dynamically and can use that for
access control, but people who bind access control to DNS really should
find a different job than administrator...
--
Lennart Poettering, Red Hat
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Stephen J Smoogen.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
