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: Learnings from a RevokeableDynamicPolicy & A Future Roadmap
Date Tue, 10 Aug 2010 11:48:58 GMT
Tom Hobbs wrote:
> Hi Peter,
>
> Something that occurs to me is where does the revoke message come from and
> who gets?
>   
The policy sends the message, the delegate receives it.

> Also, if I were a malicious programmer, is it possible for me to
> legitimately get the appropriate permission for something, then intercept
> and ignore any revokes that come my way?
No, it'll be passed by direct reference.

>   It seems risky if the client code
> is able to do this, and the master/server/revoker code assumes that it has
> revoked permissions.
>
> It feels like there's a certain amount of trust going on in the form of "If
> I tell you not to do something, I trust you not to do it."  I've got two
> young daughters; whilst okay, this approach isn't always reliable!  :-)
>   
There was some of that when based on threads, however by caching the 
AccessControlContext's that pass, there is no risk, since references to 
the objects the delegates protect will never escape, unless reflection 
permission has been granted.

So if there's a loop that calls a method many times, checkPermission 
will be called once initially, the AccessControlContext cached and while 
the current context doesn't change and no revocation occurs, there will 
be no further checkPermission calls.

The added cost will be getting the current context and checking it 
exists in the cache, this is much less work than calling implies() on 
every ProtectionDomain on the stack, which all eventually calls the policy.

Cheers,

Peter.
> Cheers,
>
> Tom
>
>
> On Tue, Aug 10, 2010 at 12:05 AM, Peter Firmstone <jini@zeus.net.au> wrote:
>
>   
>> Fred Oliver wrote:
>>
>>     
>>> Peter,
>>>
>>> Thanks again.
>>>
>>>
>>>
>>>       
>>>> Further, the
>>>>         
>>>>> revocation events are delivered to one or more of the delegates to
>>>>> force the socket to close.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> That was the original intent, however, now I'm thinking the delegate
>>>> catch
>>>> AccessControlException, thrown by a helper class, called
>>>> MethodAccessContoller, which the delegate calls prior to entering the
>>>> privileged block, performs any clean up, then re-throws the exception.
>>>>  Code
>>>> that doesn't need to do any clean up, doesn't need to catch the
>>>> exception.
>>>>
>>>>
>>>>         
>>> What happens to the thread stuck in the read on the socket when the
>>> permission it had to read was revoked after the read began? Force
>>> closing the socket will free up the thread. Otherwise the thread would
>>> eventually obtain data it shouldn't have from this read (or hang
>>> indefinitely waiting for data).
>>>
>>>
>>>       
>> Hmm, yes, it needs to be closed from another thread.
>>
>>
>>
>>     
>>>> Basically: Method call from new thread? Permission check.  Permission
>>>> revoked? Permission check again.  Previously checked Thread, no relevant
>>>> revocation's since (of same Class<Permission>)? Don't check again,
return
>>>> quickly.
>>>>
>>>> The assumption I've made is, it will be very difficult for an attacker to
>>>> predict when a thread will access a method on the delegate, then later,
>>>> be
>>>> called by that very same thread, so his class can call the delegate
>>>> unchecked.  Any thoughts on this?  Am I overlooking something?
>>>>
>>>>
>>>>         
>>> What happens when a delegate is passed back and forth between trusted
>>> (having permission) and untrusted (not having permission) code (on the
>>> same thread)? If you cached based on the thread, you'll get
>>> unpredictable results?
>>>
>>>
>>>       
>> Yes that is a problem, so we have take a snapshot of the
>> AccessControlContext at the time of the permission check and check that it
>> is still equal() later.  I guess I could drop the thread check and just
>> check the AccessControlContext, this might be useful for thread groups etc
>> ;)
>>
>> The AccessControlContext could be cached for each Thread.
>>
>> Cheers,
>>
>> Peter.
>>
>>  Fred
>>     
>>>
>>>       
>>     
>
>   


Mime
View raw message