On Jul 31, 2010, at 11:53 PM, Peter Firmstone wrote: > A Brief evolution of java.security.Policy providers and Jini Security, please > correct me where necessary. > > Prior to Jini 2.0 security was left up to implementing developers, the > standard tools available in Java 1.2 were insufficient. You had to implement > your own SecurityManager. Or you could define Security policy's in policy > files. The AccessController still consulted the ProtectionDomain, but the > ProtectionDomain Permission's were static and unchanging. You could > implement your own policy provider for java.security.Policy, by there was no > way you could guarantee updates to the ProtectionDomain with any changes, the > ProtectionDomain used the Policy.getPermissions(ProtectionDomain) call to > obtain the PermissionCollection from the Policy. > > To enable the Jini 2.0 Security infrastructure, Sun made changes to Java > itself, in Java 1.4 ProtectionDomain's were given a new constructor that > enabled the ProtectionDomain to consult an external Policy Provider, and the > java.security.Policy gained the implies(ProtectionDomain, Permission) method, > allowing the ProtectionDomain to consult the Policy, Jini 2.0 took advantage > of this with the DynamicPolicyProvider.
Yes, I remember that Bob Scheifler did manage to shoehorn some small but important changes into the JDK, presumably these ones you mention, although I don't remember exactly. > This Policy system is a permissive system, that is security was only ever > relaxed, it cannot be tightened without restarting the JVM. > > Now we have taken a new evolutionary step, inspired by Sun's Neuromancer > Research Project's additional security needs, for a distributed object > registry, we now have a RevokeableDynamicPolicy interface. [...] > A RevokeableDynamicPolicy supports the addition or removal of > PermissionGrant's Hmmm. I remember talking with Bob and Mike Warres about this. The problem with removing permission grants is that when code is granted a permission, it can very likely squirrel away something -- an object, or another capability available through the granted permission -- that will permit it to perform the same operation again without the JVM checking for the permission again. Our conclusion was that there was probably no effective way to implement removal of permission grants. Perhaps there is something about the particulars of what you have done here to negate this argument -- and I have not had the time to check the details of your stuff myself to be sure -- but my guess is that it will be difficult or impossible to do this in an airtight manner. By the way, when working on Neuromancer, the team working on that project decided that assigning permissions to classloaders and principals was too hard. We didn't make much progress on security concerns actually, but our idea was that we would treat the entire virtual machine as a single capability zone -- no different permissions for different code, threads, principals, etc., within a single Java VM. Our hope was to keep things simple, an idea whose rightness seemed to be borne out by the complexity of developing Jini 2.0 and the difficulties that the Jini team had in plugging security holes in the model immediately afterwards (an effort I heard about but did not participate in). - Tim
