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

Sat Mar 22 04:20:29 UTC 2014

2014-03-22 3:21 GMT+01:00 Lennart Poettering <mzerqung at 0pointer.de>:

> On Sat, 22.03.14 01:20, Miloslav Trmač (mitr at volny.cz) wrote:
>
> > > Well, if you filter in postfix or ssh, then you have a domain-specific,
> > > powerful language there. You can not only match on source addresses,
> but
> > > also on user names, groups, authentication methods, connection features
> > > SASL schemes, crypto algorithms, ... It's a very good thing being able
> > > to control this in a unified, but domain-specific way.
> >
> > What's "unified" about that?
>
> Isn't that obvious? You have a single language that centralizes your
> access decisions in one place

I see what you mean now.  There are two mutually exclusive dimensions to
unify here (same for all servers / everything for one server); so it is
unordered which one is "more unified".

This is supposedly security functionality. You shouldn't build your
> security functionality on top of DNS. If you do, then you gain no
> security.
>

I have made a careful argument (quoted below).  Feel free to refute that
argument with specific objections instead of general guidelines like "you
shouldn't use DNS" that border on cargo-cult security.

> > Also, note that an organization *can* actually make DNS sufficiently
> secure
> > by using their own DNS servers that have authoritative sources for the
> > relevant domains, even without DNSSEC: this would keep out all script
> > kiddies and internet-originating attackers who can't attack the link
> > between the tcp_wrappers user and the DNS server, while still allowing
> > attacks from a compromised computer within the organization--which is
> > *exactly* the case where the domain-specific configuration would probably
> > allow access *anyway*, so the attacker might have nothing to gain by
> > subverting DNS.  (Yes, there are many possible configurations of
> > tcp_wrappers where this argument does not apply, and it does require care
> > from the administrators of the system.)
>
> And you honestly believe that people who are capable enough of setting
> up DNS locally and across the company in a secure way to do something
> like this,

The design I have described does not require *an*y special effort to secure
DNS; no DNSSec, no VPNs, no nothing.  Just use ordinary wired Ethernet, and
WPA2 for your WiFi, the way everyone already does.  (The trouble with this
design is not that it is difficult to set up, but that it doesn't mean
every possible configuration that uses DNS is reliable.)

Specifically, basically any small business with a single internal network
and a single Linux do-it-all box (which includes a DNS server for the
internal network) can AFAICT quite safely use tcp_wrappers to restrict
access to some services of the server to the internal network.

are also crazy enough to do their access control with tcpwrap
> rather maybe firewalls and basically every other possibility?
>

Saying that they would be crazy to use it in a thread that is explicitly
discussing whether there are reasonable uses is circular reasoning.

You guys claim on one hand that tcpwrap is wonderfully designed and
> super-easy to use.
>

I don't remember anybody claiming that; paying a little more attention to
what people are actually saying might help mutual understanding.

> We *do* need to *actually understand* the user's motivations for using
> > tcp_wrappers, not just dismiss it as security theater--because even if it
> > *were* security theater, if we don't know why the users are doing this
> they
> > are likely to do it in the new system as well, and we will end up with
> even
> > a bigger mess implementing the same security theater.
>
> We *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and
> about 30% logic that is much better, safer, and more comprehensively
> implemented in a firewall.
>

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.

If this is being used (and AFAICT it is), then the users have a reason.
Per the general rule, that reason is likely to be right for their
situation; and even if they shouldn't be using it, their thought process is
likely to be rational, only based on some incorrect assumption.  *Why* are
administrators using this?

If they could be using the firewall and are using hosts_access instead, why?
If they are using DNS-based rules, why?
(If they are using ident, why?  Well, let's assume that the precondition is
false and skip this :) )

If we don't know, how can we expect to improve security by removing this
functionality?  Either the users were right to use this, and they will be
hurt by the removal, or they were wrong but will apply the same incorrect
assumption to something else.

Alternatively, feel free to assume that most users of tcp_wrappers are
mistaken; what are they mistaken about, what do we need to fix in the tools
or documentation so that they actually start designing their networks and
using their systems securely?

If we remove tcp_wrappers, we should expect the users to want to preserve
the existing functionality--migrating existing tested configuration to a
different file is far easier than designing different security controls.
So, users will probably take their existing, secure or insecure,
hosts_access rules, and move them as they are, secure or insecure, into
application-specific configuration (your "basically every other
possibility").  In such case, quite a few Fedora developers would have done
extra work, many users would have done extra work, and *nothing* would have
improved about security of the system; on the contrary, we would only have
the additional problems of many independent slightly differing
implementations.

*Why* are people using this?
     Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140322/543f77d2/attachment.html>