Re: Reimplementing SocketPermission

[Simon IJskes - QCG <si...@qcg.nl>]

On 31-12-11 14:33, Peter wrote:
> Any thoughts or experience replacing java classes using the -Xbootclasspath option?
> This means creating a new java.net.SocketPermission, completely replacing it and SocketPermissionCollection in the jvm libraries.

My gut feeling tells me, do not go there. Is this because of the lookup 
problem? We can assume river is only used on LAN's and when we use it on 
the internet, do we still need the socketpermission as a safety measure?

Gr. Sim


-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: Reimplementing SocketPermission

[Peter <ji...@zeus.net.au>]

Seems like the only way to deal with the problem is via work arounds.

Using a Comparator<SocketPermission> is one option, to arrange the permissions so:

1. Identical check using comparator.
2. wild cards are checked.
3. IP addresses.
4. Last check domain name addresses.

Alternatively, we can use a replacement inside the policy only, or ConcurrentPermissions, as an internal implementation detail.

ConcurrentPermissions can be used inside ProtectionDomain too, important, since PD's internal Permissions are checked after the policy, if it doesn't imply.  Also static ProtectionDomains never consult the policy, their classloader might during their construction, but that's it.

The policy also merges the ProtectionDomain's internal Permissions, with the policy.

In addition, use dnsjava as the name service provider, and make dns lookup and reverse lookup property options.

Cheers,

Peter.
----- Original message -----
> On 1/3/2012 3:18 AM, Simon IJskes - QCG wrote:
> > On 31-12-11 14:33, Peter wrote:
> > > Any thoughts or experience replacing java classes using the
> > > -Xbootclasspath option?
> > > This means creating a new java.net.SocketPermission, completely
> > > replacing it and SocketPermissionCollection in the jvm libraries.
> >
> > My gut feeling tells me, do not go there. Is this because of the lookup
> > problem? We can assume river is only used on LAN's and when we use it on
> > the internet, do we still need the socketpermission as a safety measure?
>
> In addition to any technical issues, we would need permission from
> Oracle. The -Xbootclasspath documentation points out that "Applications
> that use this option for the purpose of overriding a class in rt.jar
> should not be deployed as doing so would contravene the Java 2 Runtime
> Environment binary code license.".
>
> My own gut feeling is that we would be very unlikely to get that
> permission, especially when the override might weaken security.
>
> Patricia

Re: Reimplementing SocketPermission

[Patricia Shanahan <pa...@acm.org>]

On 1/3/2012 3:18 AM, Simon IJskes - QCG wrote:
> On 31-12-11 14:33, Peter wrote:
>> Any thoughts or experience replacing java classes using the
>> -Xbootclasspath option?
>> This means creating a new java.net.SocketPermission, completely
>> replacing it and SocketPermissionCollection in the jvm libraries.
>
> My gut feeling tells me, do not go there. Is this because of the lookup
> problem? We can assume river is only used on LAN's and when we use it on
> the internet, do we still need the socketpermission as a safety measure?

In addition to any technical issues, we would need permission from
Oracle. The -Xbootclasspath documentation points out that "Applications
that use this option for the purpose of overriding a class in rt.jar
should not be deployed as doing so would contravene the Java 2 Runtime
Environment binary code license.".

My own gut feeling is that we would be very unlikely to get that
permission, especially when the override might weaken security.

Patricia

Re: Reimplementing SocketPermission

[Peter Firmstone <ji...@zeus.net.au>]

Simon IJskes - QCG wrote:
> On 31-12-11 14:33, Peter wrote:
>> Any thoughts or experience replacing java classes using the 
>> -Xbootclasspath option?
>> This means creating a new java.net.SocketPermission, completely 
>> replacing it and SocketPermissionCollection in the jvm libraries.
>
> My gut feeling tells me, do not go there. Is this because of the 
> lookup problem? 
Partly motivated by that and partly by the history of deployment issues 
with DNS.

> We can assume river is only used on LAN's and when we use it on the 
> internet, do we still need the socketpermission as a safety measure?

Unfortunately more so, since the internet would be accessed from the 
LAN, the SocketPermission would determine if a user and proxy was 
allowed / trusted to connect to the LAN (if the proxy is from the 
internet), apart from the default return address granted to the proxy by 
default (DownloadPermission granted to a codebase signer is the only way 
to stop it).   A LAN may contain hosts who's only protection against 
attack is the firewall.

If a replacement implementation of SocketPermission behaved as expected 
by default, we could provide a configuration property that says don't do 
reverse dns lookups or don't perform dns lookup at all when resolving 
SocketPermission.

If there are no dns lookups the administrator (who sets the property) 
then know's that the policy files must have IP addresses as well as 
domain names for SocketPermission's since one wouldn't imply or equal 
the other.

Generally dns lookup works, it's the reverse lookup's that cause 
problems, when the DNS server doesn't support it or is misconfigured.

Still, Dan might be right, the solution probably is to just use another 
provider that detects a misconfigured environment and responds 
accordingly.  In that case a SocketPermission still won't imply IP 
addresses to domain names, but it might handle the situation in a much 
more timely manner.  This would behave identically to a 
reimplementation, albeit with a little less thread safety and broken 
behaviour of equals and hashCode, but I'm successfully getting around 
that using a Comparator and being selective about the Collections used 
to store Permissions.

The dns provider probably needs it's own background thread, so it can 
perform housekeeping and monitoring of the local dns environment, rather 
than wait for a request thread before doing so.  www.dnsjava.org is 
probably a good starting point.

Cheers,

Peter.