Hmmm, scratches beard, ok, you're right, up for some brainstorming?
1. If I reimplement SocketPermission, what sort of behaviour do we need?
2. Or a faster DNS provider? www.xbill.org/dnsjava -
*sun.net.spi.nameservice.provider.1=dns,dnsjava*
A Comparator is good for ensuring the Permission object's are sorted
into an efficient order before creating a PermissionCollection. The
Comparator isn't much good for a cache that contains a previously
checked Permission, since equals will be executed (I don't currently
cache SocketPermission for this reason). Collection.contains(Permission
p)?
With a SecurityManager and our own PolicyFile implementation, it is
possible to replace / substitute SocketPermission, from both ends, but
both the policy and SM must be in place or it won't work. PolicyFile
must be instantiated early, or we risk having static ProtectionDomain's
that still contain java.net.SocketPermission. ConcurrentPermissions, a
replacement for Permissions that ProtectionDomain's use to hold static
Permissions could also be used to convert any stray SocketPermission
objects.
One question I've asked myself when creating my own policy
implementation was CodeSource.implies(CodeSource cs), the implementation
seemed like a bad idea, it uses DNS, an attacker could use DNS cache
poisoning to gain elevated permission using an untrusted CodeSource URL,
simply because the policy thinks the CodeSource is implied. I changed
PolicyFile to specifically not use CodeSource.implies(). In reality a
signer Certificate is required to identify the CodeSource with any level
of trust.
Now a IPv4 address can be converted to an IPv6, so IP addresses could be
converted to IPv6 format and compared. Host names could be compared
using string comparison. But without DNS an IP address couldn't equal a
domain name and a domain name couldn't be resolved to imply an IP address.
The intended purpose of SocketPermission is to check if a user and or
code is allowed to connect, listen, etc to a network address. How can
we trust the DNS to give the right information?
How do we know the DNS has resolved a domain name correctly?
The most logical way to identify the remote end, would be via a
connection that requires it to authenticate. We have that now with
secure JERI.
SocketPermission only makes a decision whether to allow a connection or
not, that's it.
Without DNS, the policy admin would have to enter SocketPermission
grants for domain names and IP addresses (manual duplication), so it
seems DNS is there for convenience.
Using RemotePolicy for a djinn group, we could have an administrator
node, resolve all current domain names (and reverse lookup IP addresses)
in the djinn policy file and update all group member nodes with
duplicated SocketPermission's for IP address and domain name forms.
Then none of the nodes would need to perform DNS resolution. Again that
requires our own SocketPermission implementation.
Cheers,
Peter.
Dan Creswell wrote:
IMHO, workarounds like this are asking for trouble. You're assuming
certain rational actions (a decent toString) on behalf of some other
programmer in the presence of evidence that says they aren't rational
- i.e. they have a poor equals and/or a poor hashCode implementation.
Combine that with putting the mechanism "under the covers" and I feel
that's a nasty piece of dark magic brewing that'll give us problems
later.
An explicit workaround option is supported in typical collections via
a Comparator, yes, that means others have to write some code but it
also means the troubles they're facing with equals and hashCode are
"in your face".
Happy Christmas,
Dan.
On 23 December 2011 02:06, Peter Firmstone <j...@zeus.net.au> wrote:
There's another way around poorly written equals() and hashCode()
implementations.
In my reference collection utilities, I have strong, weak and soft
references, there are variations on these based on identity or equality.
Well, I've just thought of another that might help out when poor equals
implementations exist:
toString()?
first check both objects have the same class, then compare the results of
toString(), and use toString().hashCode() for hashCode's.
I could call this String equality, when toString isn't overridden it prints
the reference address so this is compatible with identity based equality
also.
This would fix all those nasty equals implementations for use in collections
without requiring any work on the developers part.
Cheers,
Peter.
Peter wrote:
SocketPermissionCollection adds SocketPermission at the head of its
internal list. This change was made in jdk 1.2.2_005 bug 4301064 related
to reverse dns lookup delays for applets.
This indicates that the tail of the last policy file parsed, is added last
to the policy and hence at the head of that List.
It's also worth noting that the standard policy provider included with
the jvm is in force until the preferred policy provider is completely
initiated, after reading all policy files. So it's likely that the standard
java policy is read last by our policy provider implementation.
In summary a list of SocketPermissions need to be sorted beginning from
those that cause long dns delays, to wildcard based permissions, so the
wildcard perms are added last and hence checked first by any implies calls.
I've got two options on how to solve this:
1. Get rid of PermissionCollection based caches altogether and generate
PermissionCollection's on demand.
2 Replace the PermissionCollection cache with a List<Permission> based
cache, generate Permissioncollection's on demand. Sort the List after
creation, before publishing, replace the list on write.
Option 2 could be implemented in ConcurrentPermissions, a replacement for
java.security.Permissions.
Option 1 would be implemented by the policy.
In addition, to allow the security manager to cache the results of
permission checks for SocketPermission, I can create a wrapper class, where
equals and hashcode are based purely on the string representation. This
allows very rapid repeated permission checks.
Looks like I can get around the SocketPermission, CodeSource and URL
headaches, relatively unscathed.
N.B. Anyone care to try out, or seriously performance test the new
PreferredClassProvider?
Cheers,
Peter.
----- Original message -----
Actually, more significantly for me is that the default localhost
SocketPermission is checked before a more lenient SocketPermission. In
theory,
one should be able to introspect SocketPermission instances and determine
that
one may be automatically implied by the other so can be skipped, possibly
saving
a lookup. Chris
Peter Firmstone wrote:
A big problem with the current implementation is SocketPermission blocks
other permission checks from proceeding.
