The obvious issue is that Java's Applet Security manager was initially exploitable in Java-1.0, because the remote DNS config could be negotiated with, by the applet, to return a local network address so that name based checks would allow local network scanning to occur. We need to make sure we don't open that door, again.
The DNS library services, in Java should keep this from happening, unless the default caching is changed to allow expiration. Gregg Sent from my iPhone On Apr 28, 2013, at 5:44 AM, Peter Firmstone <j...@zeus.net.au> wrote: > All qa suite tests are now passing > All jtreg tests that are known to pass are passing (those that depend on a > Kerberos Domain server and Squid do not as expected). > > To address concurrency,the issue of threads starting during service server > construction (River-418), a new interface has been created: > > com.sun.jini.start.Starter > > Any service that uses the start package can now delay starting of threads > until construction is complete. This prevents services from becoming visible > to other threads before construction is complete, for compliance with the JMM. > > All services except for Fiddler and Norm have been converted to use Starter, > remaining services will be updated in River 2.3.1 > > A JIRA issue for each service will be created to document progress on Starter > conversion. > > Security Infrastructure changes: > > 1. org.apache.river.api.security.ConcurrentPolicyFile - copied > from Apache Harmony and refactored for immutable concurrency, > all implies permission checks are performed thread confined to > avoid synchronization issues with PermissionCollection > implementations. PermissonCollection's are not shared among > threads. Permissions are granted to Principals and CodeSource > signed by Certificate and / or by URI, not URL, this avoids > consulting DNS to determine URL identity. > 2. net.jini.security.policy.DynamicPolicyProvider has been > reimplemented. > > Changes to Policy.getPermissions(CodeSource codesource) semantics: > > The contract for Policy.getPermissions changed in Java 6: > <quote> > > getPermissions > public PermissionCollection getPermissions(CodeSource codesource) > Return a PermissionCollection object containing the set of > permissions granted to the specified CodeSource. > Applications are discouraged from calling this method since this > operation may not be supported by all policy implementations. > Applications should solely rely on the implies method to perform > policy checks. If an application absolutely must call a > getPermissions method, it should call > getPermissions(ProtectionDomain). > The default implementation of this method returns > Policy.UNSUPPORTED_EMPTY_COLLECTION. This method can be > overridden if the policy implementation can return a set of > permissions granted to a CodeSource. > > Parameters: > codesource - the CodeSource to which the returned > PermissionCollection has been granted. > Returns: > a set of permissions granted to the specified CodeSource. If > this operation is supported, the returned set of permissions > must be a new mutable instance and it must support heterogeneous > Permission types. If this operation is not supported, > Policy.UNSUPPORTED_EMPTY_COLLECTION is returned. > > </quote> > > DynamicPolicy grants are no longer included when > getPermissions(CodeSource codesource) is called, instead the method > delegates to the underlying encapsulated base policy. > > ConcurrentPolicyFile getPermissions(CodeSource codesource) is > implemented to return either privileged Permissions (CodeSource's > granted AllPermission), or UNSUPPORTED_EMPTY_COLLECTION. This is > purely a performance optimisation, allowing > ProtectionDomain.implies(Permission permission) to return early for > privileged ProtectionDomain's without consulting the Policy provider. > > > Changes to ClassLoader infrastructure regarding codebase annotations: > > 1. URL is no longer used as a Key in Collections. This changes > ClassLoading semantics slightly: > 1. Codebase annotations will be normalised as URI according to > RFC3986 and compared for equality, remote code with > identical codebases annotations will share a URLClassLoader. > 2. Previously codebases with different annotations would share > a URLClassLoader if they resolved to the same IP address. > This made firewall traversal and codebase replication > difficult and also prevented the use of dynamically assigned > IP addresses for codebase servers. > 2. A new class org.apache.river.api.net.Uri has been provided to > implement RFC3986 compliance, it was copied from Apache Harmony > and updated to strictly comply with RFC3986. This new class does > not support Serializable and is final and immutable. It can be > serialized in it's string form and reconstructed remotely by > passing a string to its constructor. It has identical method > signatures to java.net.URI. Originally java.net.URI was utilised, > however while it implements RFC2396 and RFC2732, it doesn't > strictly comply and allows additional characters that should be > escaped in RFC2396, this means that a strictly compliant RFC2396 > URI in normalized for may not be equal to a java.net.URI. In > addition java.net.URI didn't support escaped characters in host > names, which would prevent registered domains from some Locales > from being used in codebase strings. > 3. URL and URN are both URI, previously only URL's were legal, so the > expanded form also allows URN to be utilised legally as codebase > annotations, this includes Rio's maven artifact URN scheme. > 4. PreferredClassLoader no longer lazily loads the preferred list, > instead this is loaded during construction. > > While these seem like huge semantic changes, the end result is codebase > annotations will still resolve to their correct ClassLoader as they always > have, but instead of using DNS to determine an IP addresses (in the case of > http and httpmd URL's), identity will be based on the RFC3986 normalized form > of the codebase string. The ClassLoader will still use URL providers for > resolving codebases. For the real oddball case, where a developer expects > three separate domain codebase annotations to resolve to the same IP address > and use the same ClassLoader, that won't work anymore. > > This won't be rushed out the door, plenty of time will be allowed for testing. >
