Agreed, remember --dry-run will give you a preview of what's to come in a merge if you have concerns...
On 10 January 2012 10:08, Tom Hobbs <[email protected]> wrote: > 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" <[email protected]> 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.
