From sgodsell at hotmail.com Wed Feb 6 20:57:16 2008 From: sgodsell at hotmail.com (Sean Godsell) Date: Wed, 6 Feb 2008 23:57:16 -0500 Subject: Javasss (Safe secure sandbox) Message-ID: Hello again openjdk people, I have added a number of new features and cleaned up some of the functions that were added previously. Javasss enhances the openjdk in a number of areas. The following is a list of enhancements: - Overwrite and lock users file paths to a specific base path - All temporary files can automatically be created in the base path without any program change to existing applications - You can limit the amount of storage being used in a path or file - You can limit the # of file and directories being created in path - You can make any path read only or read/write - You can allow or deny whether libraries can be loaded from a path. - You can allow or deny whether native methods can be used from a path. - You can have multiple paths to allow users to read or write to with different limiting storage and or # or files and directories. - You can limit the number of threads and thread priority. - You can limit the maximum # of windows being created. - You can allow or deny hosts and ports being used. - You can allow or deny execution of runtime process. - You can limit the amount of socket traffic throughput in bytes per second - All items can be controlled in a simple properties file - Allow threads to have different paths, and/or lock every new thread with certain paths - Allow users to configure thread paths using a key. - Existing programs and applications can run without any changes or modifications. A security manager cannot even do half the items previously listed. There is complete source code and examples at the following site: http://sourceforge.net/projects/javasss/ Sean Godsell _________________________________________________________________ From sgodsell at hotmail.com Tue Feb 12 13:50:59 2008 From: sgodsell at hotmail.com (Sean Godsell) Date: Tue, 12 Feb 2008 16:50:59 -0500 Subject: Javasss (Safe secure sandbox) for jdk 6 and openjdk 7 Message-ID: Hello once again openjdk people, Previously Javass required openjdk 7. Now it supports jdk 6 update 3. The following is a list of enhancements: - Overwrite and lock users file paths to a specific base path (like chroot in unix) - All temporary files can automatically be created in the base path without any program change to existing applications - You can limit the amount of storage being used in a path or file - You can limit the # of file and directories being created in path - You can make any path read only or read/write - You can allow or deny whether libraries can be loaded from a path. - You can allow or deny whether native methods can be used from a path. - You can have multiple paths to allow users to read or write to with different limiting storage and or # or files and directories. - You can limit the number of threads and thread priority. - You can limit the maximum # of windows being created. - You can allow or deny hosts and ports being used. - You can allow or deny execution of runtime process. - You can limit the amount of socket traffic throughput in bytes per second - All items can be controlled in a simple properties file - Allow threads to have different paths, and/or lock every new thread with certain paths - Allow users to configure thread paths using a key. - Existing programs and applications can run without any changes or modifications. A security manager cannot even do half the items previously listed. There is complete source code and examples are at the following site: http://javasss.sourceforge.net/ Sean Godsell _________________________________________________________________ From apj.lists at code3.dk Mon Feb 18 01:28:50 2008 From: apj.lists at code3.dk (Andreas Plesner Jacobsen) Date: Mon, 18 Feb 2008 10:28:50 +0100 Subject: Caching behaviour of InetAddress Message-ID: <47B94FD2.3010209@code3.dk> I've recently been introduced to the caching behaviour of InetAddress, and I think it may be improved. The javadoc reads: The InetAddress class has a cache to store successful as well as unsuccessful host name resolutions. The positive caching is there to guard against DNS spoofing attacks; while the negative caching is used to improve performance. And that is all fine and well, but for multihomed hosts, I believe the current behaviour is 1) Not documented properly 2) Not correct Coming from a unix-world, I'm used to the resolver handing out RR-replies in random order, and thus I would expect InetAddress to do the same, but a short test (courtesy of Arne Vajh?j) shows that InetAddress.getByName() will return the same IP for a lookup when the lookup is performed within the 10-second range of the cache: public class DNSLookup { private static final String MS = "www.microsoft.com"; public static void main(String[] args) throws Exception { Map m = new HashMap(); InetAddress[] all = InetAddress.getAllByName(MS); for(InetAddress one : all) { m.put(one.getHostAddress(), 0); } for(int i = 0; i < 10000; i++) { String ms = InetAddress.getByName(MS).getHostAddress(); m.put(ms, m.get(ms) + 1); } for(Entry e : m.entrySet()) { System.out.println(e.getKey() + ": " + e.getValue()); } } } Outputs: 207.46.19.190: 0 207.46.193.254: 10000 207.46.192.254: 0 207.46.19.254: 0 While I would expect the replies to distribute to about 2500 on each (which it will if the cache isn't used). -- Andreas From Alan.Bateman at Sun.COM Mon Feb 18 02:17:11 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 18 Feb 2008 10:17:11 +0000 Subject: Caching behaviour of InetAddress In-Reply-To: <47B94FD2.3010209@code3.dk> References: <47B94FD2.3010209@code3.dk> Message-ID: <47B95B27.7070002@sun.com> Andreas Plesner Jacobsen wrote: > I've recently been introduced to the caching behaviour of InetAddress, > and I think it may be improved. > > The javadoc reads: > The InetAddress class has a cache to store successful as well as > unsuccessful host name resolutions. The positive caching is there to > guard against DNS spoofing attacks; while the negative caching is used > to improve performance. > > And that is all fine and well, but for multihomed hosts, I believe the > current behaviour is > > 1) Not documented properly > 2) Not correct > > Coming from a unix-world, I'm used to the resolver handing out > RR-replies in random order, and thus I would expect InetAddress to do > the same, The specification could be improved but changing InetAddress.getByName to return a random address is a significant change that could break existing applications. It might be better to define a new method, perhaps "getAnyByName", that randomly chooses one of the cached addresses for the host (or does a lookup if not in the cache). That would be a convenience to applications to avoid needing to invoke getAllByName and choose an address themselves. -Alan. From apj.lists at code3.dk Mon Feb 18 03:43:03 2008 From: apj.lists at code3.dk (Andreas Plesner Jacobsen) Date: Mon, 18 Feb 2008 12:43:03 +0100 Subject: Caching behaviour of InetAddress In-Reply-To: <47B95B27.7070002@sun.com> References: <47B94FD2.3010209@code3.dk> <47B95B27.7070002@sun.com> Message-ID: <47B96F47.2060102@code3.dk> Alan Bateman wrote: Alan, > The specification could be improved but changing InetAddress.getByName > to return a random address is a significant change that could break > existing applications. It might be better to define a new method, > perhaps "getAnyByName", that randomly chooses one of the cached > addresses for the host (or does a lookup if not in the cache). That > would be a convenience to applications to avoid needing to invoke > getAllByName and choose an address themselves. I don't think it's a significant change, since that's how getByName() acts when the cache entries time out, so changing it would make it act a lot more consistently. Actually, I think it's worth debating whether or not InetAddress should cache lookups at all, I think it's more fitting to delegate that to the underlying OS. -- Andreas From Alan.Bateman at Sun.COM Mon Feb 18 04:49:48 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 18 Feb 2008 12:49:48 +0000 Subject: Caching behaviour of InetAddress In-Reply-To: <47B96F47.2060102@code3.dk> References: <47B94FD2.3010209@code3.dk> <47B95B27.7070002@sun.com> <47B96F47.2060102@code3.dk> Message-ID: <47B97EEC.5020704@sun.com> Andreas Plesner Jacobsen wrote: > : > I don't think it's a significant change, since that's how getByName() > acts when the cache entries time out, so changing it would make it act > a lot more consistently. > > Actually, I think it's worth debating whether or not InetAddress > should cache lookups at all, I think it's more fitting to delegate > that to the underlying OS. > Search for a ~1996 paper on DNS spoofing attacks from Princeton University as that gives useful background on this topic and is the original reason for the caching. When a security manager is set then it caches forever and getByName will always return the same address. There was some capitulation on this topic in jdk6 so that it doesn't cache forever when there isn't a security manager. There was analysis done at the time on the implications of the change but I don't know if that included changing the behavior of the getByName method (Michael?). -Alan. From apj.lists at code3.dk Mon Feb 18 05:16:31 2008 From: apj.lists at code3.dk (Andreas Plesner Jacobsen) Date: Mon, 18 Feb 2008 14:16:31 +0100 Subject: Caching behaviour of InetAddress In-Reply-To: <47B97EEC.5020704@sun.com> References: <47B94FD2.3010209@code3.dk> <47B95B27.7070002@sun.com> <47B96F47.2060102@code3.dk> <47B97EEC.5020704@sun.com> Message-ID: <47B9852F.7090908@code3.dk> Alan Bateman wrote: Alan, >> I don't think it's a significant change, since that's how getByName() >> acts when the cache entries time out, so changing it would make it act >> a lot more consistently. >> >> Actually, I think it's worth debating whether or not InetAddress >> should cache lookups at all, I think it's more fitting to delegate >> that to the underlying OS. >> > Search for a ~1996 paper on DNS spoofing attacks from Princeton > University as that gives useful background on this topic and is the > original reason for the caching. When a security manager is set then it > caches forever and getByName will always return the same address. There > was some capitulation on this topic in jdk6 so that it doesn't cache > forever when there isn't a security manager. There was analysis done at > the time on the implications of the change but I don't know if that > included changing the behavior of the getByName method (Michael?). Thanks for the background info. Incidentally, that brings us to a third inconsistent operating mode of getByName(), so we're up to three different behaviours: 1. When running under a security manager, we cache forever 2. When not running under a security manager, with more than ten seconds between name lookups, we return random answers (at least if the dns reply is delivered randomized to java) 3. When not running under a security manager, with less than ten seconds between name lookups, we return the same answer on every query. As far as I can see from what I've been able to google, the problem lies in that applets may be cheated in connecting to a different host, and that this makes it easier (actually invisible) to the applet author that there may be more than one record in the dns reply. I may not have a lot of say in this, but I still don't feel this is the right solution. Do you perhaps have some more resources to any previous discussion on the subject? I think I'd prefer breaking compatibility and introducing a caching InetAddress implementation for applet programmers and make InetAddress work as expected. But then again, I don't have to do the required cleanup :) -- Andreas From jdp at syntelos.com Mon Feb 18 09:39:43 2008 From: jdp at syntelos.com (John Pritchard) Date: Mon, 18 Feb 2008 12:39:43 -0500 Subject: Caching behaviour of InetAddress In-Reply-To: <47B96F47.2060102@code3.dk> References: <47B94FD2.3010209@code3.dk> <47B95B27.7070002@sun.com> <47B96F47.2060102@code3.dk> Message-ID: a) The java.net cache is replicating the NSCD (OS caching), which are the appropriate layer for this kind of caching. b) If a security policy requires a kind of caching, then the replaceable and extensible security manager architecture should be used for this. On 2/18/08, Andreas Plesner Jacobsen wrote: > > > Actually, I think it's worth debating whether or not InetAddress should > cache lookups at all, I think it's more fitting to delegate that to the > underlying OS. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20080218/4212fac8/attachment.html From fw at deneb.enyo.de Mon Feb 18 09:56:03 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 18 Feb 2008 18:56:03 +0100 Subject: Caching behaviour of InetAddress In-Reply-To: <47B97EEC.5020704@sun.com> (Alan Bateman's message of "Mon, 18 Feb 2008 12:49:48 +0000") References: <47B94FD2.3010209@code3.dk> <47B95B27.7070002@sun.com> <47B96F47.2060102@code3.dk> <47B97EEC.5020704@sun.com> Message-ID: <873arqrvws.fsf@mid.deneb.enyo.de> * Alan Bateman: > Search for a ~1996 paper on DNS spoofing attacks from Princeton > University as that gives useful background on this topic and is the > original reason for the caching. That paper is probably out of date by now. Interaction of expiry and poisoning hasn't been fully understood back then. > When a security manager is set then it caches forever and getByName > will always return the same address. This is probably related to DNS pinning/anti-pinning attacks, not to cache poisoning. From Alan.Bateman at Sun.COM Mon Feb 18 13:37:50 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 18 Feb 2008 21:37:50 +0000 Subject: Caching behaviour of InetAddress In-Reply-To: <47B9852F.7090908@code3.dk> References: <47B94FD2.3010209@code3.dk> <47B95B27.7070002@sun.com> <47B96F47.2060102@code3.dk> <47B97EEC.5020704@sun.com> <47B9852F.7090908@code3.dk> Message-ID: <47B9FAAE.5080501@sun.com> Andreas Plesner Jacobsen wrote: > : > Thanks for the background info. Incidentally, that brings us to a > third inconsistent operating mode of getByName(), so we're up to three > different behaviours: > > 1. When running under a security manager, we cache forever > 2. When not running under a security manager, with more than ten > seconds between name lookups, we return random answers (at least if > the dns reply is delivered randomized to java) > 3. When not running under a security manager, with less than ten > seconds between name lookups, we return the same answer on every query. That is basically it as per jdk6 (caching was always forever in releases prior to jdk6). The spec doesn't require a particular caching period and in the Sun implementation it is 30 seconds (and 10 seconds for unsuccessful lookups). You can of course configure the caching period or disable it completely by means of security properties. > > As far as I can see from what I've been able to google, the problem > lies in that applets may be cheated in connecting to a different host, > and that this makes it easier (actually invisible) to the applet > author that there may be more than one record in the dns reply. > > I may not have a lot of say in this, but I still don't feel this is > the right solution. Do you perhaps have some more resources to any > previous discussion on the subject? I don't think this issue has been discussed on this mailing list but if you google for DNS pinning you should find a lot on this topic. Many other technologies and products (browsers, plug-ins, ...) also pin. -Alan. From damjan.jov at gmail.com Sat Feb 23 02:39:37 2008 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Sat, 23 Feb 2008 12:39:37 +0200 Subject: 4212324: Packets sent to broadcast address not received on servers bound to specific addr Message-ID: <9e89675b0802230239i2ecbeec7l983604600097ad29@mail.gmail.com> Hi Is this the right place to discuss/post patches for Java 1.7? If not, what is? Sun's websites are so confusing... Has there been any work on the bug I referred to in the subject? If not, read on. On most operating systems (Windows being the exception as usual), binding to a non-0.0.0.0 IP address prevents you receiving UDP broadcasts, while binding to 0.0.0.0 makes it harder (or, in Java, currently impossible) to tell which network interface the UDP datagram arrived from. There is 2 ways to determine the interface without resorting to raw sockets: you can use SO_BINDTODEVICE (on systems that support it) to limit the socket to accept datagrams from only the given interface, or you can use recvmsg() and look at the IP_PKTINFO ancillary data. SO_BINDTODEVICE doesn't exist on Windows and requires root access on Linux so that's out of the question, but recvmsg() and equivalents exist on Windows >= XP and Linux (and probably Solaris too). Now you'd think that's all, problem solved, but in fact it's only the beginning. The in_pktinfo and in6_pktinfo structures have (overall) 3 fields: ipi_ifindex (the 1-based network interface index), ipi_spec_dst (the IP address of ipi_ifindex), and ipi_addr (the destination IP address in the packet's header). ipi_spec_dst is not equal to ipi_addr in the case of UDP broadcasts. The fun starts when you observe that IPv6, and on Windows even IPv4, has no ipi_spec_dst, and it's impossible to tell the interface from ipi_addr (which could be eg. 255.255.255.255 or 0.0.0.0), which leaves only ipi_ifindex. I'm concerned that looking up and building java.net.NetworkInterface from ipi_ifindex is too costly in CPU time and memory to do for each java.net.DatagramPacket, especially since most UDP sockets don't deal with broadcasts. Is it okay if I put the index into java.net.DatagramPacket, and provide a java.net.NetworkInterface.getByIndex() method that will do that for applications that need it? Also java.nio.channels.DatagramChannel seems very limited compared to java.net.DatagramSocket, is it worth patching? >From what I've observed in Java 1.6 on Linux, java.net.NetworkInterface.getNetworkInterfaces() doesn't list interfaces without an IP address, even if they are up. The documentation says it will list all interfaces, so is this a bug? Bye Damjan From Alan.Bateman at Sun.COM Sat Feb 23 05:55:22 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sat, 23 Feb 2008 13:55:22 +0000 Subject: 4212324: Packets sent to broadcast address not received on servers bound to specific addr In-Reply-To: <9e89675b0802230239i2ecbeec7l983604600097ad29@mail.gmail.com> References: <9e89675b0802230239i2ecbeec7l983604600097ad29@mail.gmail.com> Message-ID: <47C025CA.6070705@sun.com> Damjan Jovanovic wrote: > Hi > > Is this the right place to discuss/post patches for Java 1.7? If not, > what is? Sun's websites are so confusing... > Yes, this is right place. > Has there been any work on the bug I referred to in the subject? If > not, read on. > Michael McMahon is probably the best person to reply to you on this. Last year he had a proposal and implementation that updated DatagramPacket with methods to obtain the datagram destination address and the network interface that it was received on. I believe he parked it temporarily to work on some higher priority tasks with a view to coming back to it later. [ Michael - can you give an updated status on this? ] > : > > Also java.nio.channels.DatagramChannel seems very limited compared to > java.net.DatagramSocket, is it worth patching? > DatagramChannel is more suited to applications where the socket is connected or where non-blocking is required. Aside a DHCP server, I haven't come across many applications needing access to the ancillary data. If required then it would be possible to have DatagramChannel define a new receive method that returns this information but it may not be worth it. > >From what I've observed in Java 1.6 on Linux, > java.net.NetworkInterface.getNetworkInterfaces() doesn't list > interfaces without an IP address, even if they are up. The > documentation says it will list all interfaces, so is this a bug? > The specification should probably be clarified here as that assertion may be too strong or ambiguous. On Linux, the interfaces are enumerated using the SIOCGIFCONF ioctl which, if I recall, is tied to the socket protocol and so only returns address with IPv4 addresses (to check this I would suggest stepping through in the debugger to see the names and index of the interfaces that are returned). When this was implemented back in 1.4 I recall the equivalent ioctl to get interfaces with IPv6 addresses wasn't implemented on Linux so we had to pull this from /proc. -Alan. From Michael.McMahon at Sun.COM Mon Feb 25 02:11:54 2008 From: Michael.McMahon at Sun.COM (Michael McMahon) Date: Mon, 25 Feb 2008 10:11:54 +0000 Subject: 4212324: Packets sent to broadcast address not received on servers bound to specific addr In-Reply-To: <47C025CA.6070705@sun.com> References: <9e89675b0802230239i2ecbeec7l983604600097ad29@mail.gmail.com> <47C025CA.6070705@sun.com> Message-ID: <47C2946A.4090500@sun.com> Alan, Damjan, The following new API was approved by the CCC to deal with this request. Add new methods to java.net.DatagramPacket /** * Returns the destination IP address that the packet * was sent to, assuming this contains a received datagram, and * that the underlying implementation is able to provide the information. * Returns null otherwise. * * @return the destination IP address of this datagram. */ public InetAddress getDestinationAddress() /** * Returns the {@link NetworkInterace} that the packet was received * through, assuming this contains a received datagram, and * that the underlying implementation is able to provide the information. * Returns null otherwise. * * @return the NetworkInterface that received the datagram */ public NetworkInterface getReceivedInterface () An implementation was done, but was not completed. If anyone would like to take the code, and finish it off, please let me know. Thanks Michael. Alan Bateman wrote: > Damjan Jovanovic wrote: >> Hi >> >> Is this the right place to discuss/post patches for Java 1.7? If not, >> what is? Sun's websites are so confusing... >> > Yes, this is right place. > >> Has there been any work on the bug I referred to in the subject? If >> not, read on. >> > Michael McMahon is probably the best person to reply to you on this. > Last year he had a proposal and implementation that updated > DatagramPacket with methods to obtain the datagram destination address > and the network interface that it was received on. I believe he parked > it temporarily to work on some higher priority tasks with a view to > coming back to it later. [ Michael - can you give an updated status on > this? ] > > >> : >> >> Also java.nio.channels.DatagramChannel seems very limited compared to >> java.net.DatagramSocket, is it worth patching? >> > DatagramChannel is more suited to applications where the socket is > connected or where non-blocking is required. Aside a DHCP server, I > haven't come across many applications needing access to the ancillary > data. If required then it would be possible to have DatagramChannel > define a new receive method that returns this information but it may > not be worth it. > >> >From what I've observed in Java 1.6 on Linux, >> java.net.NetworkInterface.getNetworkInterfaces() doesn't list >> interfaces without an IP address, even if they are up. The >> documentation says it will list all interfaces, so is this a bug? >> > The specification should probably be clarified here as that assertion > may be too strong or ambiguous. On Linux, the interfaces are > enumerated using the SIOCGIFCONF ioctl which, if I recall, is tied to > the socket protocol and so only returns address with IPv4 addresses > (to check this I would suggest stepping through in the debugger to see > the names and index of the interfaces that are returned). When this > was implemented back in 1.4 I recall the equivalent ioctl to get > interfaces with IPv6 addresses wasn't implemented on Linux so we had > to pull this from /proc. > > -Alan. >