Let SVN do the merge, your changes might be extensive but I doubt there has been much movement in those files since you checked them out. So the merge will probably be more of a replace.
I'm hoping to get some coding done in the next few weeks - at last! So we might have enough changes soon for a release. Keep up the good work, Peter. Sent via mobile device, please forgive typos and spacing errors. On 10 Jan 2012 06:20, "Peter" <j...@zeus.net.au> wrote: > The new security manager and policies are almost ready to merge back into > trunk. > > Any svn merge tips would be much appreciated. > > First, I'd like to move some policy implementation classes that are at > present public in org.apache.river.*, into package private net.jini.* > namespaces, to reduce the public api. > > Not all of the code will be included, classes, like ConcurrentPermissions > (and all policy cache associated classes), even though far better than > Permissions, will be discarded, as recent developments (eliminating policy > cache) have made them redundant. > > DelegatePermission is still there, designed to work with delegate wrapper > classes that encapsulate sockets and and file handles, to enable removal of > temporarily granted permissions. > > Example: A downloaded proxy is granted a SocketPermission to contact its > server, if during deserialisation, the proxy modifies some public static > fields (java.xml.* vulnerabilities ring a bell?) by replacing some platform > classes with its own, it leaves some of its own proxy code on the stack > context. The proxy after being downloaded is found to be untrusted and > discarded. > > Every time the object the proxy has injected into the platform is > accessed, it steals information and sends it back to its originating host. > > If a DelegatePermission(SocketPermission p) is granted instead, the proxy > recieves a socket that denies access when the permission is revoked, when > trust can't be verified. > > The proxy could still perform a denial of service, by causing an out of > memory error during deserialisation. > > DelegatePermission can also be used to grant temporary or limited access > to Principals, eg after downloading 1GB, downloads are revoked and > regranted at the next monthly cycle, something sililar could be used to > limit writes to the file system. > > Obviously you'll need to buffer the input or output streams, to balance > how often checks are performed, that is, if you choose to utilise it. > > A DelegateSocketFactory that can be used to encapsulate existing > SocketFactory's will be released at a later date to enable > DelegatePermission controlled streams and channels. Note any > ProtectionDomains with SocketPermission will still have access to the same > channel. > > DelegatePermission is intended to be a dynamically or runtime granted > Permission. > > To function it requires a DelegateSecurityManager, each stack context > domain must have permission either for the DelegatePermission or it's > representative Permission. > > This was one motivation for a securitymanager cache, it needed to be as > fast as possible and non blocking, unlike policy cache. > > Using delegates is of course optional. > > The other thing I was toying with was using deny as well as grant in > policy files: > > Where denials would be checked first by the policy prior to checking > grants: > > So you could deny a proxy access to the local network, whilst granting it > access to the entire internet, with two simple policy statements. > > Or you could allow access to a directory, but deny access to a user policy > file contained in that directory, for principal based grants. > > The syntax would be identical to a grant statement in policy files, except > deny replaces grant. > > But then I realised despite the advantages, it adds complexity, because > the deny statement could have unintended scope narrowing / widening > consequences and Permissions like SocketPermission don't work as well as > intended, it would be simpler to dynamically grant Permissions on an as > needed basis. > > So any last remaining traces of deny must be removed. > > Instead of using deny in policy grants, I figure that proxy's can > optionally include permissions.perms files under META-INF in their jar > files as a hint to clients. By using the least priviledge model and > limiting the GrantPermissions given to Principals administrators can limit > Permissions users can grant to proxy's. > > The proxy developers would need to be aware they might not be granted all > the permissions they'd like and offer reduced functionality by catching > SecurityException. > > Regards, > > Peter.
