river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Learnings from a RevokeableDynamicPolicy & A Future Roadmap
Date Sun, 15 Aug 2010 03:57:42 GMT
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

View raw message