Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 SRS0=0fDiZg=PX=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.35 as permitted sender)
Message-ID: <4C6BEBC2.1050708@wonderly.org>
Date: Wed, 18 Aug 2010 09:18:42 -0500
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Learnings from a RevokeableDynamicPolicy & A Future Roadmap
References: <4C54EFBA.30907@zeus.net.au>
	<A5CF53B3-318D-48DD-89BC-3B53E7C628A1@gmail.com>
	<4C5BEAC7.1020400@zeus.net.au>	<4C5CF8DF.8040302@zeus.net.au>
	<AANLkTimuPMjSXZeH3uOCRzD3WP2D382xzO667RhGK1MR@mail.gmail.com>
	<4C5FE2A7.1010804@zeus.net.au>
	<AANLkTimci4q0-JQkpbnMAvsd=msHRBX6+Os3moMbWuQJ@mail.gmail.com>
	<4C607389.20109@zeus.net.au>
	<AANLkTinSJUboR+3Un55QDMCEkFQWkDjP_MA3VHjS3dRx@mail.gmail.com>
	<4C6249B6.9070601@zeus.net.au>
	<AANLkTikteptpdpWUn9pN5=f34m=K0hnFGtmChJJLoP6x@mail.gmail.com>
	<AANLkTik=Bcqj-A98UoQvsAXM=abGq0NSaSOMQH7SNYdp@mail.gmail.com>
	<4C675F3D.4030907@zeus.net.au>	<4C6765B6.9000709@zeus.net.au>
	<AANLkTinwq3wNt=-FPUf2_83Z1_KmW1UYoCTciYo7rkVG@mail.gmail.com>
	<4C68B72D.7090507@zeus.net.au>
	<AANLkTimVosGQ1kNZN5A=Q0M9uYNjySNodsdSF+caL2c=@mail.gmail.com>
 <AANLkTimLUxjUt3yqENLPhCCiS9L7AkGbQgMdXd+2iP-U@mail.gmail.com>
 <4C69D277.9080805@zeus.net.au>
In-Reply-To: <4C69D277.9080805@zeus.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregg Wonderly <gregg@wonderly.org>

Peter Firmstone wrote:
> Fred Oliver wrote:
>> To at least partially answer my own question, I think that the answer
>> is that the socket can't be closed (at least in all cases).
>>
>> If the delegate for a resource has multiple users (codebases,
>> principals, etc.) then closing the resource because permission for one
>> of the users has been revoked denies access to the resource by the
>> remaining valid users. (This allows a denial of service attack.) And
>> then, if you can't close the resource (socket), you can't kick loose
>> the no longer trusted thread blocked reading from it. You may be able
>> to determine the special case of no user retaining access (everyone's
>> access was revoked) and can then close the resource.
>>
>> In the standard security model, there are no checks for
>> reading/writing sockets. Allowing revocation means that checks must be
>> added for each individual read or write call on the socket streams. Is
>> that level of performance satisfactory?
>>   
> 
> I've just spotted a possible performance improvement.
> 
> We can eliminate the end() call in the finally block, put all the 
> checkPermission calls there instead.  This substantially reduces the 
> caching operations.  Perhaps we can manage the Socket some other way, we 
> just block unauthorised access using the delegate?
> 
> try {
>    // Do some processing
>    return something;
> } finally {
>    ECM.checkPermission(Collection<Permission> permissions);
> }
> 
> The current expense for making a Permission call via ECM (remembering 
> the first is always going to be expensive), currently requires the three 
> ECM calls in succession:
> 
> begin();
> checkPermission(perm);
> end();
> 
> begin():
> 
>   1. Associate the thread with the reaper.
> 
> 
> checkPermission(perm):
> 
>   1. Obtain the read lock;
>   2. Add the current thread to the execution cache.
>   3. Associate the current AccessControlContext with the current thread
>   4. Check if the AccessControlContext has been checked for this
>      Permission previously.
>   5. If it has been checked before, return, else do
>      AccessController.checkPermission(perm), cache the result if it
>      succeeds.
> 
> Each end():
> 
>   1. Obtain the read lock;
>   2. Remove the thread and reaper from the cache.
>   3. Remove the thread association with the AccessControlContext.
>   4. Remove the thread from the execution cache.
> 
>      This could be simplified to (no reaper or thread caching):
> 
> checkPermission(perms)
> 
>   1. Obtain the read lock;
>   2. For each Permission, check if the current AccessControlContext has
>      been checked for this Permission previously, if so return.
>      (HashMap lookup - fast).
>   3. If the AccessControlContext hasn't been checked previously, do
>      AccessController.checkPermission(perm), cache the result if it
>      succeeds, then return.
> 
> So for performance reasons, it looks like we need to be considering some 
> other way to manage the Socket, the ECM would serve us better if we kept 
> it simple?
> 
> I think your earlier suggestion of an event notification might be more 
> useful, if provided as a parameter in the checkPermission call, in the 
> event of failure, an event would be generated, the delegate could then 
> decide what action to take.  If it only had one user, then it knows to 
> close the Socket, if it has multiple users, it might just keep score.
> 
> This stops the transmission of data from unauthorised code, but it 
> doesn't close the socket.

If there is an interface such as:

public interface PermissionChangeDelegate {
	public void permissionGranted( Permissions p );
	public void permissionRevoked( Permissions p );
}

and the code invokes a method with a signature like:

public void checkPermission( Permissions p, PermissionChangeDelegate del );

and the provider of this method is associated with grants and revokes such that 
it can know who checking for such permission uses, then there can be a callback 
to all the delegates at revocation, and the socket can be closed as appropriate 
based on the knowledge of the PermissionChangeDelegate.

But, in the end, I really do think that this is too low of a level for 
permission checks.  Open ended resources should not be visible in the API 
without some sort of wrapper class.  I create subclasses of OutputStream and 
InputStream etc. to hold references of sockets and perform checks there by not 
using the SecurityManager, but by using the JDBC backed database which is 
completely cached in memory in the auth.dev.java.net project.  With that 
facility, I don't have to worry about what granularity of "Permission" has been 
designed into the JVM resources.  Instead, I can put an appropriately grained 
control layer on top of my API, and that layer can do what is needed to manage 
things, because every API call is checked, and if a permission is revoked, that 
fact is instantly reflected into all security delegates, and the APIs will be 
controlled based on the granularity I've decided on.

Gregg Wonderly