Fred,
I've thought about it some more. When there were smart people trying to
solve this problem what were the constraints they faced at the time?
When Java 1.4 was released, a new Policy method was added,
implies(ProtectionDomain, Permission), and the ProtectionDomain modified
to allow dynamic ProtectionDomain's via a new 4 parameter constructor.
Prior to Java 1.4, the method used to get the Permission's from the
policy, for a ProtectionDomain, was indirectly via
policy.getPermissions(ProtectionDomain), this was handed to the
ProtectionDomain constructor, and was static, if
ProtectionDomain.toString() was called, this caused the ProtectionDomain
to merge any new Permissions from the policy with those in it's private
Permissions collection.
So anybody at that time, had to consider the problem of supporting pre
Java 1.4 program's, policy's and SecurityManager implementations. To
enable dynamic revocation of a Permission, you cannot return any dynamic
Permission's via the policy.getPermissions method, they would become
merged within a ProtectionDomain's Permissions, checked after the policy
in a dynamic PD returning true after the policy returned false ( the
policy is not checked at all in a static PD).
Then there is the problem of escaping references to objects with
privileged behaviour for some existing Permission's.
Now, we no longer have to contend with supporting JVM's prior to 1.4, so
this issue has been resolved by time, the second issue, hopefully now
the first is resolved can be resolved now too, with new Permission's,
Security Delegates, and optimised repeated checkPermission() calls.
Some benefit's of revocation (and I suspect you know of others); the
reuse of ClassLoader's and the avoidance of re verification of bytecode,
another might be the possibility of simplifying cross domain login's and
the separation of concerns for "code trust" and "user trust". You can't
trust code forever, at some point, even signed trusted code will
experience a security flaw, in which case you can revoke some trust of
that particular code, since it has been found untrustworthy in some respect.
There's a document at https://issues.apache.org/jira/browse/RIVER-341
This is intended to cover the separation of implementation from API and
evolution of API (by extension) and evolution of implementation by
versioning (replacement).
For Services, implementation's can be versioned, by adding version
metadata into the jar file, they can be updated, URL's can be annotated
with version information and message digests, PermissionGrant's can be
utilised to determine the level of trust dynamically based on an
implementation version and signer certificates.
There are many possibilities.
The issue's with fine grained permission's I'd like to see solved with
some new tools, Service Entry's and jar files containing the
Permission's they require.
Best Regards,
Peter.
Fred Oliver wrote:
It's so much easier to ask questions than provide answers. This is
such a difficult problem you are trying to solve that other very smart
people have chosen other directions.
Fred
