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: Distributed Garbage Collection & Security - InvocationConstraints
Date Tue, 21 Jun 2011 02:22:48 GMT
Peter Firmstone wrote:
> Peter Jones wrote:
>> On Jun 19, 2011, at 5:37 AM, Peter Firmstone wrote:
>>> The easiest way to set DGC constraints would be via configuration.
>>> Perhaps the reason this hasn't been implemented previously is, the 
>>> constraints would apply to all services that use DGC, so if you've 
>>> set Authentication and Integrity as minimal constraints, then this 
>>> would apply to all services.
>> As mentioned offline, I'm not sure how much of this I can page into 
>> my consciousness at the moment.
>> Configuring the server-side constraints for DGC could probably be 
>> supported with additional parameters to the export process (and thus 
>> set via configuration).  The bigger issue, I think, is what client 
>> constraints to apply, and what client subject to use, when JERI's 
>> client-side DGC system (defined within BasicObjectEndpoint) makes 
>> "dirty" and "clean" calls on behalf of the application.  In the 
>> traditional RMI DGC model, those calls happen implicitly as remote 
>> references appear and disappear from a JVM.  But in the JERI security 
>> model, the client application controls the security behavior of 
>> remote calls by explicitly (with respect to the standard JERI layers) 
>> specifying constraints and controlling the current subject.
>> So when the system wants to make a "dirty" or "clean" call for a 
>> given remote reference (forget batching for the moment), what 
>> constraints to apply, or what subject to use?  There didn't seem to 
>> be an answer, without requiring the client application to interact 
>> with the DGC system more explicitly, which would be a significant 
>> change from the RMI DGC model-- and, I think, not something that 
>> seemed worth investing effort on at the time, especially given that 
>> Jini services didn't seem to make use of RMI's DGC functionality in 
>> practice anyway (instead they used higher-level leasing mechanisms to 
>> detect client "failure", and most interest was around just being 
>> disable DGC for Jini services).
> The higher level mechanisms I've seen duplicate a lot of 
> functionality, eg use weak reference notifications, leases etc, this 
> is what DGC uses, so it would appear to save some work.
> Restoring the Subject after privileged execution blocks can be 
> expensive too.
> I guess the main concern is, the call hasn't been tampered with and 
> originates from the correct client, eg the clientID hasn't been forged 
> or altered.
> SSLEndpoint can provide integrity but it requires at least server 
> authentication, but it's the client that needs authenticating.
> I wonder if ImplRef can be used to store the Subject at the server, 
> different services might use different authenticating subjects.
> The client would need an object table that tracked the authenticating 
> subject used for each BasicObjectEndpoint.
The problem with the above statement is it would cause problems when the 
DGC client wanted to update the lease for all BasicObjectEndpoint's 
Uuid's in a single dirty call for a specific Endpoint.

A possible solution:

A DGC client would need to group BasicObjectEnpoints authenticated with 
identical subjects and submit each grouping separately in repeated dirty 
calls.  This would result in the Lease being updated at the server each 
time, but with Targets for each Uuid (representing BasicObjectEndpoints) 
sequence numbers must not be incremented for each subsequent call in the 
batch, Targets maintain their own record of sequence numbers for each 
client and would not be updated until a call is made with the particular 
targets Uuid included in the dirty call's Uuid[] ids parameter.

This means that clean calls could be batched in the same way with 
identical sequence numbers for an Endpoint with multiple 
BasicObjectEndpoints with uncommon Subjects and Targets would be removed 
from the lease for each clean call, until no targets remain in the lease.

Because the sequence number doesn't need to be incremented for these 
single Endpoint uncommon Subject groupings, it preserves the sequencing 
required to identify the order of clean and dirty calls for each Endpoint.

Any dirty calls that fail with SecurityException cannot be retried and 
it wouldn't be safe to unmarshall the proxy, or if it did, garbage 
collection would be disabled.  The DgcServer would require a minimal set 
of constraints or a ClientMinPrincipal consistent among all the services 
that server provides to prevent the SecurityException occurring.

If the client of an arbitrary service with DGC enabled, lets the 
reference to the proxy escape locally, then even though another subject 
might be unauthorised to interact with that service due to constraints, 
the act of holding a local reference to the arbitary service's proxy 
will keep DGC updating the lease using the credentials of the a recorded 

This doesn't seem to be a big security issue however, it cannot be used 
for denial of service, by holding onto some resources without causing 
much load.

So each BasicObjectEndpoint would need to keep a Set of weakly 
referenced Subjects, that recorded the Subject when a newCall succeeds, 
to be used by AbstractDgcClient to find a common Subject among all 
BasicObjectEndpoints for a specific Endpoint, in most cases it is likely 
only one call would need to be sent for a single common Subject, but on 
occasion multiple calls for different Subjects for an Endpoint would 
need to be sent.  The weakly referenced Subject means the 
BasicObjectEndpoint doesn't prevent local GC of the Subject, in case it 
logs out and another Subject is still using the BasicObjectEndpoint.

AbstractDgcClient would need some modifications so it doesn't increment 
the sequence number for additional calls required for an Endpoint with 
uncommon subjects in their BasicObjectEndpoints .

It is possible that a Target might not be removed by a clean call from a 
lease in the DgcServer, if the clean call cannot authenticate (eg the 
Subject has logged off and Subject has been locally garbage collected 
while a strong reference is still held by the client to the 
BasicObjectEndpoint) if that lease continues to be updated for other 
targets at the client (a target represents a remote object) where the 
lease for a particular client has a collection of targets, garbage 
collection of that target will be delayed until the lease is allowed to 
expire by the client.   This seems to be a reasonable assumption.

It also doesn't require any changes in the server's DGC logic.

See any holes?



View raw message