在处理cname反向查找时,java.net.SocketPermission中有错误 [英] Is there a bug in java.net.SocketPermission when dealing with cname reverse lookup

查看:166
本文介绍了在处理cname反向查找时,java.net.SocketPermission中有错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

请考虑以下代码段:

(在这种情况下为OpenJDK 6b24-1.11.5-0ubuntu1〜12.10.1,因为所有的JVM 6和7都显得无关紧要Oracle和OpenJDK都有相同的行为)

(in this case OpenJDK 6b24-1.11.5-0ubuntu1~12.10.1, which appears irrelevant since all the JVMs 6&7 both Oracle and OpenJDK have the same behavior)

SocketPermission toCheck = new SocketPermission("www.google.ca", "resolve");

SocketPermission checker = new SocketPermission("*.ca:80", "connect");

System.out.println("Result: " + checker.implies(toCheck));

checker = new SocketPermission("*.1e100.net:80", "connect");

System.out.println("Result: " + checker.implies(toCheck));

我得到的结果是:

Result: false
Result: true

这个问题似乎是JVM执行反向查找来验证地址是否与解析的域实际匹配。

The issue seems to be that the JVM does a reverse lookup to verify that the address actually matches against the resolved domain.

www.google.ca域显示以下内容:

A dig lookup of the www.google.ca domain reveals the following:

[rotty@rotty-desktop ~]$ dig www.google.ca ANY

; <<>> DiG 9.8.1-P1 <<>> www.google.ca ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48015
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.ca.         IN  ANY

;; ANSWER SECTION:
www.google.ca.      114 IN  A   74.125.226.55
www.google.ca.      114 IN  A   74.125.226.56
www.google.ca.      114 IN  A   74.125.226.63
www.google.ca.      74  IN  AAAA    2607:f8b0:400b:801::1018

;; Query time: 27 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Jan 14 17:18:50 2013
;; MSG SIZE  rcvd: 107

此外,将结果中的第一个地址和执行DNS查找产生:

Furthermore, taking the first address in the result and performing a DNS lookup produces:

[rotty@rotty-desktop ~]$ nslookup 74.125.226.55
Server:     127.0.1.1
Address:    127.0.1.1#53

Non-authoritative answer:
55.226.125.74.in-addr.arpa  name = yyz06s06-in-f23.1e100.net.

Authoritative answers can be found from:

这似乎清楚地表明了问题。非权威的反向查询返回为域定义的第一个(本地区域)别名。

This seems to clearly demonstrate the issue. A non-authoritative reverse lookup returns the first (by locality in this case) alias defined for the domain.

这意味着我需要知道并声明任何潜在的可以解析为指定域名的底层地址的别名。

This means that I need to know, and declare, any potential aliases that may resolve to the underlying address of the specified domain name.

为什么JVM需要这样的匹配?地址确实存在的简单验证是否足以满足解决过程?地址可能有很多可能的反向映射。在实践中,这可能如何工作?

Why would the JVM require such a match? Wouldn't a simple validation that an address does in fact exist be enough for the "resolve" process to be satisfied? There may well be any number of possible reverse mappings for the address. How could this ever work in practice?

[更新] 为了澄清这个事实上与默认的java策略定义相同,请考虑以下附加示例:

[Update] In order to clarify that this in fact behaves the same with a default java policy definition, consider the following additional example:

Socket socket = new Socket("www.google.ca", 80);

socket.close();

将以下安全策略应用于以上内容:

Applying the following security policy to the above:

grant {
    permission java.net.SocketPermission "*.ca:80", "connect";
    //permission java.net.SocketPermission "*.1e100.net:80", "connect";
};

执行程序为:

java -Djava.security.manager -Djava.security.policy=../security.policy Test

结果:

Exception in thread "main" java.security.AccessControlException: access denied ("java.net.SocketPermission" "www.google.ca" "resolve")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
    at java.security.AccessController.checkPermission(AccessController.java:560)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at java.lang.SecurityManager.checkConnect(SecurityManager.java:1048)
    at java.net.InetAddress.getAllByName0(InetAddress.java:1203)
    at java.net.InetAddress.getAllByName(InetAddress.java:1127)
    at java.net.InetAddress.getAllByName(InetAddress.java:1063)
    at java.net.InetAddress.getByName(InetAddress.java:1013)
    at java.net.InetSocketAddress.<init>(InetSocketAddress.java:142)
    at java.net.Socket.<init>(Socket.java:208)
    at example.security.SocketSecurityExample.test(SocketSecurityExample.java:13)
    at example.security.SocketSecurityExample.main(SocketSecurityExample.java:9)

将策略文件更改为:

grant {
    //permission java.net.SocketPermission "*.ca:80", "connect";
    permission java.net.SocketPermission "*.1e100.net:80", "connect";
};

结果正确执行代码。

推荐答案

JVM在连接时不会采取这种行为。它构造一个包含实际主机名/ IP地址的SocketPermission,并使用conce来检查.policy文件中的任何权限是否包含该权限。

That action wouldn't be taken by the JVM when connecting. It constructs a SocketPermission containing the actual hostname/IP address and uses 'implies' to check whether any permission in the .policy file implies that permission.

这篇关于在处理cname反向查找时,java.net.SocketPermission中有错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆