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

[Miloslav Trmač <mitr@xxxxxxxx>]

2014-03-22 3:21 GMT+01:00 Lennart Poettering <mzerqung@xxxxxxxxxxx>:

On Sat, 22.03.14 01:20, Miloslav Trmač (mitr@xxxxxxxx) 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 any 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 security.

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

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct