Peter Firmstone wrote:
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,
That should read policy.getPermissions(CodeSource), and Java 1.4 onward
merged the Permissions with a ProtectionDomain.toString() call via the
call policy.getPermissions(ProtectionDomain). Anyway it would have
appeared dauntingly difficult, since there were many different
implementations at the time, things have stabilised now thankfully.
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
