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: SVN Merge
Date Wed, 11 Jan 2012 01:26:05 GMT
Having a look at any new interfaces, once we publish them we're stuck 
with them, so any thoughts or questions (Do I need to improved docs etc) 
would be appreciated.

Regards,

Peter.

Tom Hobbs wrote:
> I can try and find some time for you.  Let me know what you need and I'll
> do my best.
>
> Sent via mobile device, please forgive typos and spacing errors.
>
> On 10 Jan 2012 12:17, "Peter Firmstone" <jini@zeus.net.au> wrote:
>
>   
>> Tom & Dan, thanks for the support, we're probably looking at a dry run by
>> the weekend, right now I'm running the tests again, this run is expected to
>> pass, I'm just checking for any regressions (same code in svn).  I'll clean
>> out all the redundant code, followed by some refactoring to move new public
>> utility classes into package private where possible.
>>
>> I've you've got some time, I could use a hand to go over the new code to
>> tidy up any loose ends, make sure any new public api looks right before we
>> merge, so we can release quickly, once the merge is complete.
>>
>> At this point, the code's only been tested on sparc.
>>
>> Cheers,
>>
>> Peter.
>>
>> Dan Creswell wrote:
>>
>>     
>>> 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