Re: sandbox resources

Alexandre Rafalovitch writes:
 > At 3:16 AM +1000 10/1/97, S. Alexander Jacobson wrote:
 > >In Jigsaw, all resources are executed by Client threads.  It strikes me as
 > >difficult without substantial changes in jigsaw architecture to
 > >preallocate threadgroups for client threads which correspond to the
 > >various permissions profiles that one might be maintaining.
 > >
 > >A lookup facility that enabled a SecurityManager to check which client
 > >thread was using which resource at any given moment could then return
 > >permissions for the particular resource.  Is such a lookup facility
 > >available?  How would I use it?
 > >
 > 
 > What about this method. Instead of using Standard thread object, Jigsaw
 > would use w3c.jigsaw.http.ClientThread. This ClientThread would have an
 > extra field and a package protected getters/setters which would be used to
 > tag the resource to be run in that thread. When resource to be called is
 > identified, some code in w.j.h package would call setter on the thread and
 > set the proper value. SecurityManager would also be in that package and it
 > would have access to getter method. Alternatively, those methods (or getter
 > only) can be public but they would call securityManager to check if it can
 > be called. We would have to avoid System.setSecurityManager for the nested
 > levels though. :-{

I guess I am latenot uptodate on that subject, but here is roughly
what I had in mind (in order to determine the permissions for a given
resource). First of add some class loader handling in the
ResourceStore API: all resources loaded from a given resource store
would use that instance of a class loader, so each resource would have
a (new) getClassLoader() method - that might return null.

This per-resource class loader, would then be passed through to
children, for container resources: if directory D was loaded through
class loader C, then any children of D would be loaded through that
same class loader.

Security permissions would be indicated within that class loader; and
the Jigsaw Security manager would look for these bits in the class
loader to determine what operation is granted to the resource, for
example:

JigsawSecurityManagerImplementation
    implements JigsawSecurityInterface
{

    public boolean checkResourceStoreAccess(SecurityManager sm
                                            , File resourcestorerepository) 
        throws SecurityException
    {
        ClassLoader cl = sm.currentClassLoader();
        if ( ! cl.checkResourceAccess(resourcestorereposirory) )
            throw new SecurityException();
    }
}

Then the std jigsaw security manager would look like:

JigsawSecurityManager extends SecurityManager {
    JigsawSecurityManagerImplementation impl ;

    public boolan checkResourceStoreAccess(File repository) {
        impl.checkResorceStoreAccess(this, repository);
    }
}

Does this makes sense ? The thing I am missing from both Alexander and
Alex is why is some binding to threads needed here ?

 > This way, we can tag each thread individually and only security manager
 > would have access to that data.
 > 
 > If that is not clear, I could provide a diagram or something, but the basic
 > idea is there.

It might help, but I still need to understand the relationship with
threads.

 > Also, about SecurityManagers, could we implement nested security managers
 > with Jigsaw Security Manager being in control and the other
 > SecurityManagers could be pluged in using Strategy Design Pattern. This
 > way, we could actually implement multi-ring controls... Eg.
 > JigsawSecurityManager will make sure that servlets can only write to some
 > particular directory , but nested security manager, can actually limit them
 > to writing only some particular types of the files.

Would chaining JigsawSecurityManagerImplementation fulfill that need,
ie in above example we would have:

JigsawSecurityManagerImplementation /* Assuming the delegatin model */
    implements JigsawSecurityInterface
{
JigsawSecurityManagerImplementation chain;

    public boolean checkResourceStoreAccess(SecurityManager sm
                                            , File resourcestorerepository) 
        throws SecurityException
    {
        ClassLoader cl = sm.currentClassLoader();
        if ( ! cl.checkResourceAccess(resourcestorereposirory) )
            throw new SecurityException();
        if ( chain != null )
            chain.checkResourceStoreAccess(sm, resourcestorereposirory);
    }
}

Anselm.

Received on Friday, 10 January 1997 03:38:54 UTC