| |
Domain Name System (DNS) is one of the many weaknesses in Internet security; host applications accessed corresponding IP addresses can be misled to other places. In other words, it will connect to the wrong position, causing the middleman (man-in-the-middle) attacks and so forth. The DNSSEC protocol extension to DNS information through the establishment of a credible encrypted channels to resolve this vulnerability. After correctly configured DNSSEC, the application will be able to get reliable host information queries. About DNSSEC by trying to integrate better into the discussion GNU C library, we know that, to ensure information security DNS queries it is not so simple.
In a sense, this problem is solved years ago, we can configure a local domain name service for complete DNSSEC validation (verification) and allows the application by glibc function to use the service. DNSSEC can even be used to improve security in other areas, for example, it can carry SSH or TLS key fingerprint, so that the application can confirm that the dialogue with the correct server. However, when we hope to confirm the results of this self-proclaimed DNS with DNSSEC validation is not really been certified by the time - that is, when we want to rely on the security of DNSSEC promised, things get a bit complicated.
/etc/resolv.conf problem
From the point of view of glibc, the problem is in part because glibc itself does not do DNSSEC validation, instead of referring to the /etc/resolv.conf file server read from the file parsing and validation done, then the results returned to the application. If your application uses the underlying res_query () interfaces, the result will include a "Certified Data (authenticated data)" (AD) identification (if the domain name server is set up, then) to indicate DNSSEC validation has been successful. But they did not know glibc credit these results provide domain name server, so it really does not tell whether the application result is really reliable.
Recommendations by the glibc maintainer Carlos O'Donell proposed increase is an option (dns-strip-dnssec-ad-bit) in the resolv.conf file tells glibc unconditionally remove AD logo. This option can be set by the release, expressed DNSSEC level DNS query results are not reliable. And once established a good right environment can obtain reliable results, and then remove this option. Thus, although the problem has not been fully resolved, at least on the basis of the application has to evaluate the reliability obtained from glibc DNS query results.
A secure environment configuration should look like? This situation should be standard and not too bad: there is a local name server, through the loop (loopback) access interface, as the only access /etc/resolv.conf file entries. This domain name server should be configured to do the check, but the check fails after simply does not return any results. In most cases, the application will no longer need to be concerned about AD logo, if the results are not reliable, the application can not see. Some releases have tended to this model, but the situation is still not as some people imagine that simple.
One of the problems is that in this way the /etc/resolv.conf file into the center of the trustworthiness of the entire system. However, in a typical Linux system, there are numerous DHCP client, the network script and many more programs can modify this file. Like Paul Wouters pointed out, in a short time it is impossible to lock the file. Sometimes this change is necessary: in a diskless system startup, before starting its own domain name server is a domain name service; a whole DNS system environment will be different according to the connected network and change; Runtime in the container is also preferably configured to use the host's domain name server; and so on.
So now generally believed that the existing system in the /etc/resolv.conf file and can not be trusted. So it was suggested to add another profile (/etc/secure-resolv.conf or whatever), but this did not solve the problem fundamentally. In addition, some participants feel that even if there is a run on the loop interface name servers are not really reliable, such as Zack Weinberg even suggested that the system administrator can intentionally disable DNSSEC confirmation (validation).
Since the current system configuration is insufficient trust, it can be inferred that, in the case of improvement can obtain reliable results after, glibc needs to have a way to notify the application. AD logo can be shielded manner discussed above (or "domain name server can trust this" option In contrast, adding a display); of course, this requires a locking system to a certain extent so as not to be subject to any non /etc/resolv.conf expected changes. Petr Spacek as recommended, there is a way the idea is to provide a way to allow applications to query glibc current communication is not a local domain name server.
In glibc, which handles?
Another way is regardless of the domain name server, but to do DNSSEC glibc itself confirmed. However, such a large lump of the encryption-related code into glibc also has great resistance. This will increase the size of the library itself, so that the feeling will increase the likelihood of attack using its application. Another extended look in this direction, by the recommendations made by Zack, can confirm the relevant code into the domain name service cache daemon (nscd) inside. Because the nscd is part of glibc, glibc maintained by the developer, so to some extent, can believe that we can confirm that the correct implementation of DNSSEC. And where the communication socket nscd is open, so it can not be considered /etc/resolv.conf problem. However, Carlos fear in this way can not let those who do not want to use nscd cache function accepted by users; in his opinion, can be ruled out nscd way.
So, at least in the near future, glibc unlikely fully implemented DNSSEC confirmed the entire inquiry process. This means that if there is a security application to be used to query the domain name glibc library, the library will need to provide an identity to evaluate the results from an independent domain name server returns to what extent reliability. This almost certainly need to release or system administrator to make some definite changes. Like Simo Sorce say:
If glibc does not use explicit configuration option to notify the application domain analysis with it is credible, there would be no use ...... not change it there is a great drawbacks, because application developers will immediately recognize that they can not be trusted any information obtained from glibc, so when dealing with DNSSEC related information is simply not it.
To configure a system to normal use DNSSEC requires changes to many components of the system - this is a release of a range of problems, take time to fully resolve. In this process of change glibc's role is likely to be relatively small, but very important part: if the application does not implement its own set of domain name parsing code, glibc DNS results are likely to be the only way to ensure credible. Running multiple DNSSEC implementation in a system does not look like a safe way, so it's better to do things right.
glibc project currently no way to determine what to do with this thing, although some tags /etc/resolv.conf file looks almost ready. Such changes should require a new release; take into account the development of glibc conservative nature, it may be too late to join in February is expected to release the 2.23 version. So there will not be glibc temporarily higher security DNSSEC, but in this direction, there are some of the progress. |
|
|
|