We'll still need URL providers for class loading, so ultimately we still
need DNS to locate a codebase server. ProtectionDomain.implies( )
checks based on URI don't consult DNS like URL does, it relies on
RFC3986 normalisation of the CodeSource's URL string, it's effectively
similar to DNS caching, except that you can now allow the DNS cache to
expire without being exposed to the vulnerability. Because the jar file
has been downloaded, there's no need to go out and download it again,
DNS doesn't need to be consulted again.
For the case where DNS is already posioned, the safest option is to sign
jar files and make policy grants to Certificate's or combinations of
Certificates and URI.
To go one step further, for maximum security, we need to avoid
Serialization prior to authentication, that means the lookup service
(found using secure discovery) needs to be trusted and must not allow
registration of untrusted services and proxy's themselves need to use
secure connections also. (I know you know that Gregg, I just thought
I'd reiterate it for the benefit of others).
Cheers,
Peter.
On 29/04/2013 12:18 AM, Gregg Wonderly wrote:
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.
