<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-03-22 3:21 GMT+01:00 Lennart Poettering <span dir="ltr"><<a href="mailto:mzerqung@0pointer.de" target="_blank">mzerqung@0pointer.de</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">On Sat, 22.03.14 01:20, Miloslav Trmač (<a href="mailto:mitr@volny.cz">mitr@volny.cz</a>) wrote:<br>
<br>
> > Well, if you filter in postfix or ssh, then you have a domain-specific,<br>
> > powerful language there. You can not only match on source addresses, but<br>
> > also on user names, groups, authentication methods, connection features<br>
> > SASL schemes, crypto algorithms, ... It's a very good thing being able<br>
> > to control this in a unified, but domain-specific way.<br>
><br>
> What's "unified" about that?<br>
<br>
</div>Isn't that obvious? You have a single language that centralizes your<br>
access decisions in one place</blockquote><div><br></div><div>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".<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is supposedly security functionality. You shouldn't build your<br>
security functionality on top of DNS. If you do, then you gain no<br>
security.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Also, note that an organization *can* actually make DNS sufficiently secure<br>
<div class="">> by using their own DNS servers that have authoritative sources for the<br>
> relevant domains, even without DNSSEC: this would keep out all script<br>
> kiddies and internet-originating attackers who can't attack the link<br>
> between the tcp_wrappers user and the DNS server, while still allowing<br>
</div>> attacks from a compromised computer within the organization--which is<br>
> *exactly* the case where the domain-specific configuration would probably<br>
> allow access *anyway*, so the attacker might have nothing to gain by<br>
<div class="">> subverting DNS. (Yes, there are many possible configurations of<br>
> tcp_wrappers where this argument does not apply, and it does require care<br>
> from the administrators of the system.)<br>
<br>
</div>And you honestly believe that people who are capable enough of setting<br>
up DNS locally and across the company in a secure way to do something<br>
like this,</blockquote><div><br></div><div>The design I have described does not require <i>an</i>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.)<br>
<br>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.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> are also crazy enough to do their access control with tcpwrap<br>
rather maybe firewalls and basically every other possibility?<br></blockquote><div><br></div><div>Saying that they would be crazy to use it in a thread that is explicitly discussing whether there are reasonable uses is circular reasoning. <br>
</div><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">You guys claim on one hand that tcpwrap is wonderfully designed and<br>
super-easy to use.<br></blockquote><br></div><div>I don't remember anybody claiming that; paying a little more attention to what people are actually saying might help mutual understanding.<br></div><div><br><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> We *do* need to *actually understand* the user's motivations for using<br>
> tcp_wrappers, not just dismiss it as security theater--because even if it<br>
> *were* security theater, if we don't know why the users are doing this they<br>
<div class="">> are likely to do it in the new system as well, and we will end up with even<br>
> a bigger mess implementing the same security theater.<br>
<br>
</div>We *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and<br>
about 30% logic that is much better, safer, and more comprehensively<br>
implemented in a firewall.<br></blockquote><br></div><div class="gmail_quote">I'm not in this thread to discuss technical merits of the existing implementation. It may be 100% crappy code. <i>All</i> of what you say above may be true, but that being true about a widely-used feature <i>doesn't automatically mean that eliminating the feature increases securit</i>y.<br>
<br></div><div class="gmail_quote">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.<br>
</div><div class="gmail_quote"><br></div>I'm participating in this discussion because, as a general rule, I assume most administrators configuring security, and most users in general, <i>aren't idiots</i>. 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.<br>
<br><br>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. <i>Why</i> are administrators using this?<br>
<br>If they could be using the firewall and are using hosts_access instead, why?<br>If they are using DNS-based rules, why?<br></div><div class="gmail_extra">(If they are using ident, why? Well, let's assume that the precondition is false and skip this :) )<br>
</div><div class="gmail_extra"><br>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.<br>
<br></div><div class="gmail_extra">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?<br>
</div><div class="gmail_extra"><br><br></div><div class="gmail_extra">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 <i>nothing</i> would have improved about security of the system; on the contrary, we would only have the additional problems of many independent slightly differing implementations.<br>
<br></div><div class="gmail_extra"><i>Why</i> are people using this?<br></div><div class="gmail_extra"> Mirek</div></div>