Hi Jean-Francois, My comments are intermixed below.
Jean-Francois Arcand wrote: > Hi Glenn, here is a couple of questions regarding your SecurityManager > XML works: > > (1) All permissions seems to be stored in class SecurityPolicyBase. The > Map used to store permission is static, meaning all permissions will be > stored in (why all? doing permissions.implies will browse every > permissions instead of application-scope permission). This can be very > slow. I'm not sure I follow this. Could you expand on this? Or give me an example of a better way to return the permissions for a CodeSource? There likely is a better way to get the permissions than the code I wrote which uses an Iterator. I followed the XP method of first getting it to work, then determine what is worth optimizing. I haven't profiled this code yet. The getPermissions() method is only a one time performance hit for each individual java class load. > > (2) Child scope will always have parent scope permissions. It there a > reason? Can it be optional? Its the other way around, a parent will inherit the permissions configured for a child. This is done to make configuring your security policy easier. This is because all classes on the stack are required to have the permission (Unless a doPrivileged was invoked) for the permission to be granted. It is easier to define a specific permission just once rather than having to define it for every codebase. How you nest your SecurityPolicy elements determines the inheritance. If you nest them similar to how they get invoked in a stack trace inheritance makes the policy configuration easier. > > (3) I didn't see any 'doPrivilege', 'Subject.doAsPrivilege' etc. in your > code. I think we need to think about a notion of Tomcat > Principal/Subject to only allow Tomcat doing those kind of operations > (adding/removing permissions). This is usefull not only for your stuff, > but for all security related call. > The policy code is in package org.apache.catalina.policy, this package has both package.access and package.definition restrictions. Only code that has been granted the Runtime accessClassInPackage.org.apache.catalina.* can use the code. In the normal policy config that is only the catalina core. > (4) There is a class called sun.security.provider.PolicyFile where the > "unmarshalling' of policy statement are made. Your XML Policy file do > not define any Policy.implies method. meaning if XMLPolicy.implies is > invoked, the call will be delegated to PolicyFile.implies, who doesn't > know anything about the permission. This method will return false for > every policy.xml permission sinde they are created outside the defaut > Policy scope. If a Servlet try accessing a file that is not granted in > the policy.xml file, right now, the permission will be allowed since the > AccesController will call the Policy.implies......IMBW... > sun.security.provider.PolicyFile is just an implementation of a Policy. Which is a SUN specific implementation and not part of the java.security API. My XMLPolicy class extends the abstract Policy class which does not have an implies() method. XMLPolicy is put in place at runtime using SecurityManager.setPolicy(), at that point XMLPolicy is in control of determining what permissions have been granted to a CodeSource. Whether a servlet has permission depends on the Permissions assigned to it by the Catalina WebappClassLoader when the class is instantiated. It then uses the Policy implemenation, in this case XMLPolicy. > (5) I did not see any statement about replacing the > policy.provider=sun.security.provider.PolicyFile (using the > -Djavax.security.jacc.policy.provider= ) ? The property javax.security.jacc.policy.provider is specific to JSR 115. I though of using the policy.provider config in $JAVA_HOME/jre/lib/security/java.security. But that requires installing the all of the required jar files to implement XMLPolicy in $JAVA_HOME/jre/lib/ext. This could be a frequent tomcat support problem. So instead I designed it to replace the default PolicyFile implemenation at runtime using SecurityManager.setPolicy(). > (6) Your code define the policy configuration parts (permissions > creation). What about the policy decision part? Which classes will > enforce the permission created? The WebappClassLoader/ServletPolicyBase > have a getPermissions() method, but I was unable to make the link > between this method and the SecurityManager...Here is probably my > inexperience with Tomcat..... > The standard implementation of the SecurityManager enforces the permissions. I didn't have to do anything. The SecurityManager and ClassLoaders are closely related. You might look at the catalina WebappClassLoader. > (7) The security defined in the Deployment Descriptor may contredict the > security defined in the policy.xml file. Which one will be applied? Ex: > Access to folder X is denied by the policy.xml file, but granted to > principal A in the deployment descriptor. I didn't implement support for JAAS or JSR 115 so there is no concept of a Principal. The permission is either granted or not. Each web application Context has its own set of permissions for code loaded as a JSP, or from its /WEB-INF/lib or /WEB-INF/classes. Since each of these have a unique CodeSource from any other web application, distinct permissions can be assigned on a per web application basis. > > (8) XMLPolicy define a method getPermission(CodeBase)....its parent > define also a getPermission(ProtectionDomain). I recommend you overload > that method (get the Codebase from the ProtectionDomain) and call your > own getPermissions(Codebase). Just in case somebody like me call the > getPermission(ProtectionDomain) ;-) > According to the abstract java.security.Policy class which XMLPolicy extends there is no getPermission(ProtectionDomain) method in a Policy. Where are you finding the getPermission(ProtectionDomain)? > (9) SecurityPolicyBase.clonePermissions() method: is there a reason why > you cloning PermissionCollection? PermissionCollection are not thread > safe, but Permission are immutable...its that the reason? > Yes. > Pretty interesting. I'm sure some JSR 115 concept can apply here. I > would recommend we follow something similar, abstracting the Policy > provider hooks in Tomcat to work not only with your XMLPolicy, but with > every instance of a Policy class. This way I can easily replace your > XMLProvider by a MyOwnProvider, 115Provider, etc. This way we can keep > the -security option when starting Tomcat and by adding the > -Djavax.security.jacc.policy.provider=org.apache.catalina.policy.XMLPolicy > instead (you have something similar, but can I use it with my own Policy > provider?). > > Just recommending :-)... > Yes this can be done but it does require that the custom Policy class and any supporting jar's be installed in $JAVA_HOME/jre/lib/ext. I also needed a bit more closer coupling between Tomcat and the Policy provider to implement some of the features that were needed. BTW, if you are interested, here is a link to a presentation I did at ApacheCon 2001 on the Tomcat SecurityManager. http://kinetic.more.net/web/javaserver/security.shtml And I will be giving an updated version of this at ApacheCon 2002 in Nov. :-) Regards, Glenn ---------------------------------------------------------------------- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | ---------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
