Hi,

Just thought I'd start a conversation about proxy trust.

net.jini.security has mechanisms to establish proxy trust.

From the package discussion:

   Note that trust verification does not prevent denial-of-service
   attacks. If a proxy that uses untrusted code is unmarshalled, the
   untrusted code can execute before trust verification takes place. In
   deployments where the trusted sources of downloaded code are known
   in advance, the |RequireDlPermProvider|
   
<http://www.gigaspaces.com/docs/JiniApi/net/jini/loader/pref/RequireDlPermProvider.html>
   can be used to prevent code downloading from untrusted sources.


I'd like to continue the discussion we were having about using Maven to provision code.

If n CodeSource Entry, can advertise what archives and versions are required, then we can also narrow our lookup results to reduce codebase downloads too. But as Dennis suggested this can be used to provision trusted code.

Note the new mechanisms I've provided in RevokeableDyanmicPolicy allow trust to be changed, this might change base on events, in response to vulnerabilities. It can also be used to grant levels of trust to CodeSources signed by trusted developers, prior to downloading those sources. I'd also like to adopt OSGi's method of Documenting the Permission's required by a jar archive, in the Jar archive itself and restricting the permissions it can attain to those alone.

There is both Code Trust and Subject Trust to contend with.

One trusted code has been provisioned, then the ProxyTrust process can be followed as usual.

To quote net.jini.security again:

   When a client obtains a proxy from somewhere, normally the client
   should follow these three steps before making any remote calls
   through the proxy or handing any sensitive data to the proxy:

       * Verify that the proxy can be trusted
         
<http://www.gigaspaces.com/docs/JiniApi/net/jini/security/package-summary.html#proxy_trust>

       * Attach client constraints
         
<http://www.gigaspaces.com/docs/JiniApi/net/jini/core/constraint/package-summary.html#constraints>
         to (a copy of) the proxy
       * Grant
         
<http://www.gigaspaces.com/docs/JiniApi/net/jini/security/package-summary.html#dynamic_grants>
         permissions (such as |AuthenticationPermission|
         
<http://www.gigaspaces.com/docs/JiniApi/net/jini/security/AuthenticationPermission.html>)
         to the proxy

   The first step can be accomplished using
   |Security.verifyObjectTrust|
   
<http://www.gigaspaces.com/docs/JiniApi/net/jini/security/Security.html#verifyObjectTrust%28java.lang.Object,%20java.lang.ClassLoader,%20java.util.Collection%29>.
   The second step can be accomplished using
   |RemoteMethodControl.setConstraints|
   
<http://www.gigaspaces.com/docs/JiniApi/net/jini/core/constraint/RemoteMethodControl.html#setConstraints%28net.jini.core.constraint.MethodConstraints%29>;
   |BasicMethodConstraints|
   
<http://www.gigaspaces.com/docs/JiniApi/net/jini/constraint/BasicMethodConstraints.html>
   is a basic implementation of |MethodConstraints|
   
<http://www.gigaspaces.com/docs/JiniApi/net/jini/core/constraint/MethodConstraints.html>.
   The last step can be accomplished using |Security.grant|
   
<http://www.gigaspaces.com/docs/JiniApi/net/jini/security/Security.html#grant%28java.lang.Class,%20java.security.Permission%5B%5D%29>.

Regards,

Peter.




Reply via email to