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.
If constraints cannot be satisfied for a particular service, then DGC
would be disabled for that service? DGC would still be enabled for
other services that satisfied the constraints.
I'd like to see a secure by default release if possible.
Fixing River-142 made me realise River's DGC design is quite good, I've
utilised some of the concurrent Java 5 features to fix the delayed
garbage collection Lease processing issue, I haven't tested single
thread performance, however it should scale better due to improved
concurrency.
DGC could be quite useful for secure internet based services.
Exporter's javadoc has the following statement regarding the force
parameter in unexport:
<QUOTE>
The |force| parameter serves to indicate whether or not the caller
desires the unexport to occur even if there are known remote calls
pending or in progress to the remote object that were made possible by
this |Exporter|:
* If |force| is |true|, then the remote object will be forcibly
unexported even if there are remote calls pending or in progress,
and this method will return |true|.
* If |force| is |false|, then this acts as a hint to the
implementation that the remote object should not be unexported if
there are known remote calls pending or in progress, and this
method will either unexport the remote object and return |true| or
not unexport the remote object and return |false|. If the
implementation detects that there are indeed remote calls pending
or in progress, then it should return |false|; otherwise, it must
return |true|. If the implementation does not support being able
to unexport conditionally based on knowledge of remote calls
pending or in progress, then it must implement this method as if
|force| were always |true|.
If the remote object is unexported as a result of this method, then the
implementation may (and should, if possible) prevent remote calls in
progress from being able to communicate their results successfully.
</QUOTE>
I've updated the class Target that implements this functionality for
BasicJeriExporter, Target's unexport method now uses thread interruption
to attempt to interrupt and abort in process calls if force is
specified. Interruption has been successful with the current jeri qa
tests and can be seen in the exception output for some tests.
Cheers,
Peter.
Peter Firmstone wrote:
River doesn't currently offer constraints for DGC, it's currently
vulnerable to attacks where the attacker knows the clientID, an
attacker makes clean calls, clients are removed and the service is
garbage collected, a simple DOS attack.
Should DGC be disabled in environments where security is a concern?
Wouldn't it be better to use constraints?
In reality DGC is just a service, used to preserve liveliness of
remote objects by holding a strong reference (to another arbitrary
service associated by using the same server jvm), while clients hold a
lease or explicitly clean it.
DGC already uses the same endpoint as the associated service it
provides the DGC service for.
Can anyone see a technical reason why constraints and Subject
authentication cannot or should not be utilised?
Cheers,
Peter.
