river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: SVN Merge
Date Tue, 10 Jan 2012 10:30:18 GMT
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 <tvhobbs@googlemail.com> 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" <jini@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.

Mime
View raw message