avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Codebase level security
Date Mon, 05 Jan 2004 09:32:52 GMT
Niclas Hedhman wrote:
> Gang,
> 
> Since deployment went fairly well, I now want to look into codebase level 
> Security (scheduled for 3.4).
> 
> NOTE!!!  Please don't confuse this with Subject level Security and JAAS 
> leveraging. That is the next step. This must be sorted out first.
> 
> 
> I have in mind that for each container's classloader declaration, the 
> permissions are given;
> 
> <container>
>   <classloader>
> 
>     <classpath>
>         :
>     </classpath>
> 
>     <permissions>
>       <permission 
>         class="java.util.PropertyPermission" 
>         name="java.home" 
>         actions="read" />
>       <permission 
>         class="java.io.FilePermission"
>         name="${merlin.home}/temp/"
>         actions="read,write" />
>       <permission
>         class="java.awt.AWTPermission"
>         name="accessClipboard" />
>     </permissions>
>   </classloader>
> </container>
> 
> I hope you get the idea...


I like the approach although think we need to separate the declaration 
of permission requirement from the granting of permissions.  A 
permission requirement should be associated with a component Type (i.e. 
in meta-data) either implicitly or explicitly.  Implicit permissions can 
be established relative to things like a component declaration of a 
context entry such as "urn:avalon:home" or "urn:avalon:temp". Explicit 
permission requirements such as accessClipboard could be exposed as follows:

   <type>
     <info>
       <name>demo</name>
       <lifestyle>singleton</lifestyle>
     </info>
     <permissions>
       <permission class="java.awt.AWTPermission"
          name="accessClipboard" />
     </permissions>
     :
   </type>

Then at the container level, we can declare the granting of permissions 
based on the declarations (as per what you described above).

> 
> For nested containers, I am planning to require that the outer container also 
> declares the nested container's requirements.

Given that a nested container is basically simulating a component, the 
set of permissions granted by a nested container constitute the 
requested permissions that the nested container is making on its parent. 
  Therefore the inclusion (statically or dynamically) of a sub-container 
can be vetoed by the parent container.

> ( It would be a typical job for GUI tool to aggregate the security permissions 
> up the hierarchy. )

Possibly a combination of GUI tool and a build-time validation plug in.

> I am not planning to have the assembly figure out if the permission 
> declarations are "compatible", i.e. if the inner-container is requesting more 
> permissions than its parent container. At least not initially. I think that 
> is also more of a tool thing.

I think you need to think about this up-front but I also don't think 
it's too big an issue.

> I think that the only position where the access control context can safely be 
> established is in the BlockInvocationHandler and the 
> ApplianceInvocationHandler, which are dynamic proxies forwarding the call to 
> the component.
> 
> The main "hurdle" I see now is to get the permission elements into the 
> ClassloaderModel instance, which will create the access control context.

The ClassLoaderModel would need to be expanded to include expose of a 
PermissionModel.  The PermissionModel would be driven off a meta-data 
definition - e.g. PermissionsDirective containing multiple 
PermissionDirective instances.  The PermissionsDirective would be 
created using XMLContainmentProfileCreator (and would need to be 
externalizable through XMLContainmentProfileWriter).

A PermissionModel would be instantiated using the PermissionsDirective 
meta-data as part of the ClassLoaderModel creation (which is where the 
classloader is itself created).

Cheers, Stephen.

> Any comments so far???
> 
> Niclas
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


-- 
|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/                               |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message