river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Oliver <fkoli...@gmail.com>
Subject Re: Does this look ok?
Date Sun, 22 Aug 2010 21:55:37 GMT
On Fri, Aug 20, 2010 at 6:38 PM, Peter Firmstone <jini@zeus.net.au> wrote:

I haven't had time to look over the code...

What does recycling the classloader mean? There is already a
classloader cache for codebases, so that a multiple references to the
same codebase will give the same classloader.

Beyond that, could you say more about reliance on grants to codebases
(as opposed to subjects) being the important part?

Let's say you have a service S in a VM which is the place where you
are concerned about permission revocation. Now add a client A which
calls a method in S, passing in a smart proxy located with a URL
served by A. At this point, you wish to allow or disallow certain
actions by the smart proxy running in S?

What if client B attempts the same operation with a smart proxy served
by B? Are you concerned about granting different permissions to the
proxies from A and B?

What if client B attempts the same operation with a smart proxy served
by A? (B makes the call specifying A's codebase.)

What if a hostile smart proxy from B loads the smart proxy from A and
manipulates it in S?

Fred


> Fred Oliver wrote:
>>
>> Peter,
>>
>> I'll try to take look over the weekend.
>>
>> In general, I am concerned that the implementation is driving the
>> security model when it should be the other way around.
>>
>>
>
> Yes that has happened, as my understanding of the platform improves during
> implementation.  I also realised during implementation, that revocation was
> not the Delegate's concern, in spite of the fact that for proper Revocation,
> delegates must be utilised.
>
> However what I really want is a simple way to add and remove some
> Permission's from the policy and to ensure that when they have been removed,
> no protected references have escaped.
>
>> Part of my concern is that I don't understand the application. Could
>> you explain more about why permissions would be revoked in your
>> application?
>>
>
> Two uses:
>
> The first is to allow ClassLoader recycling, for multiple smart proxy based
> services (one at a time), with identical CodeSource's.
>
> The second, is enabling limited trust for Java Smart Proxy's from unknown
> untrusted Services.
>
> Providing some basic Permission's to enable the Smart proxy to access:
>
>  1. Network
>  2. Sound
>  3. Microphone
>  4. WebCam
>  5. GPS.
>
> vi a ServiceUI, or other services.
>
> If the client has any remaining objects from the untrusted Service, to
> prevent remnant objects's from continuing to utilise the Permission's for
> ongoing communication after the Service has been discarded.
>
>>  - What resources does your application need to give and then revoke
>> permissions for?
>>
>
> See above.
>
>>  - To whom (principal, codebase, etc.) are permissions given and taken
>> away?
>>
>
> Definitely CodeSources.
>
>>  - Are resources shared between multiple principals, codebases, etc.?
>>
>
> The network will be.  The codebases may be common, for services, but
> generally not shared at the same time, although it is possible if permission
> grant's are delayed until all services sharing a codebase have verified
> their proxy's.  If a ClassLoader is recycled, the client and new Service
> will need to verify the new proxy, before any permission's are granted.
>
>> I think it would be much easier to restrict the problem scope if you
>> only needed to associate principals with resources, if that were the
>> case.
>>
>
> Like using a guest account for services?  Using a DomainCombiner to inject
> principals.
>
> Cheers,
>
> Peter.
>
>> Fred
>>
>>
>
>

Mime
View raw message