river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kleczek <michal.klec...@xpro.biz>
Subject Re: Towards Internet Jini Services (trust)
Date Fri, 08 Oct 2010 11:50:44 GMT
Some more thoughts.

There is one scenario that is not covered here:

I get an service, verify the module that loads its class using a 
ModuleAuthority that I trust. This service in turn downloads some other 
objects that it verified. There is no way I can delegate trust verification to 
the service - I must trust Modules (actually ModuleAuthorities) of those 
subsequent objects.

1. I have to have a way to allow or disallow module trust delegation (looks 
like a case for dynamic permission grants)
2. This delegation has to be automatic (IOW the service does not have to do 
anything - it is solely my decision to delegate)

Any ideas?
Michal

On Thursday 07 of October 2010 21:57:48 Michal Kleczek wrote:
> So...
> I've spent a day on some thinking and prototyping and hopefully I got an
> idea. Here is an outline:
> 
> 1. We annotate classes with an object implementing Module interface:
> interface Module {
>   //methods copied from ClassLoading but there is no annotation argument
>   Class loadClass(...);
>   Class loadProxyClass();
> }
> This makes class loading pluggable - a service can designate it's own class
> loading mechanism.
> Note that the methods take boolean verifyCodebaseIntegrity argument. I
> think it could be replaced by placing constraints on a Module.
> 
> 2. Before using a Module we prepare it using a ProxyPreparer - that way we
> make sure we trust the Module before letting it load classes
> 
> 3. We have a default implementation of Module that delegates class loading
> to ClassLoading:
> RmiModule implements Module {
>   private String annotation;
> }
> 
> 4. There is a single instance of RmiModule called BOOTSTRAP that we use to
> load RmiModule class. This is implemented in:
> RmiModule {
> ...
>     static Module getModuleOf(final Class cl) {
>         /*
>          * RmiModule is equivalent of String annotation
>          * so it should be available locally
>          */
>         if (cl == RmiModule.class) {
>             return getBootstrap();
>         }
> 
>         final ClassLoader loader = getClassLoader(cl);
>         if (loader instanceof ModuleClassLoader) {
>             return ((ModuleClassLoader) loader).getModule();
> 
>         }
> 
>         final String annotation = RMIClassLoader.getClassAnnotation(cl);
>         return annotation != null ? RmiModule.getInstance(
>            annotation,getModuleTrust(loader)) : getBootstrap();
>     }
> ...
> }
> 
> 5. We use the above method in annotateClass and annotateProxyClass of our
> MarshalOutputStream
> 
> 6. RmiModule can be verified by ProxyTrustVerifier. It's ProxyTrust
> implementation delegates TrustVerifier retrieval to:
> public interface ModuleAuthority extends Remote {
>     TrustVerifier getModuleVerifier() throws RemoteException;
> }
> 
> 7. We implement some helper functions that make it simpler to export a
> service and provide its clients with either third party ModuleAuthority or
> designate itself as a ModuleAuthority.
> 
> 8. Before all this is implemented in PreferredClassProvider we have to
> cache association between a ClassLoader and a Module. It's implemented in
> RmiModule.
> 
> 9. If we implement it in PreferredClassProvider our ClassLoaders can keep a
> reference to associated Module
> 
> 10. If we implement it in PreferredClassProvider we can have different
> ClassLoaders for the same annotation but different ModuleAuthority - that
> would actually allow us to grant permissions to Modules - before that two
> different Modules with the same annotation are going to share permissions.
> 
> I've attached a prototype implementation (note - it is a proto-proto-
> prototype) so that you guys can verify if you have some spare time.
> Don't know if mailing list server allows attachments.
> 
> Michal
> 
> On Tuesday 05 of October 2010 16:48:22 Michal Kleczek wrote:
> > On Tuesday 05 of October 2010 16:36:47 Gregg Wonderly wrote:
> > > On 10/1/2010 12:38 PM, Michal Kleczek wrote:
> > > > When I think about it some more - the below idea is not enough and we
> > > > need a more general solution.
> > > > How about class annotation not being a String but rather an object...
> > > > I have to give it some more thought.
> > > 
> > > There are been some thought and discussion about doing this.  It is
> > > possible, but the problem becomes that if you send an object with the
> > > annotation, then how does the receiver unmarshall that object?  Is that
> > > object something that everyone knows about ahead of time?
> > 
> > My line of thought was - yes. It would have to be something similar to
> > ProxyTrust - a factory to receive an Unmarshaller.
> > I haven't really given it enough thought.
> > 
> > But I am more and more convinced that doing that at the higher (proxy
> > preparation) level - as I described it earlier - could actually be
> > enough.
> > 
> > Michal

Mime
View raw message