Hi Glenn, see below...
Glenn Nielsen wrote: > 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? My mistake. I did not properly analyse the inner class CodeSourcePermission. Your approach is fast enough. > > > 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. ...except when the refreshPolicy is invoked. You can get permissions from the CodeSourcePermission's collection instead of re-creating all the permissions (I doubt the permission file will change entirely). You will pay the price of an if....But I'm not sure you can do that since Castor is in the picture. Can you check if a permission exists before you create it? > > >> >> (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. OK. > > >> >> (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. OK, but when Tomcat is embedded in another container (JBOSS, J2EE), the AccessControlContext will not be associated with a principal/subject. It's not a problem, but might be an improvement. > > > > >> (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. For whatever reason,. I was under the impression you where extending that class.Maybe because I'm reading in english and thinking in french ;-) > > > 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(). OK...too much 115 works! I was under the impression that property was already defined. > > >> (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 Sorry, I wasn't clear. The SecurityManager will reenforce the permission checking, but with the current WebappLoader, I expect that some permission with not get resolved, based on their codebase (and then translated to java.security.UnresolvedPermission). I guest I will have to play with it and comes with a clear use case. The way permission are resolved slightly change between jdk 1.3 and 1.4. My little experience tell me we can find strange behaviour there.....but just a guest. > > >> (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. My example was more: you denied access to file A in policy.xml, but file A is a valid Servlet, where the authentication constraint is defined in the DD. I guest it's a developper problem.... > > >> >> (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)? In 1.4...I guest we should not use it. > > >> (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. What about having something like -Dorg.apache.catalina.provider="...." ? This way we can then get that value and call the setPolicy(). Let me think about a "looser" coupling. Maybe It's not feasible, but I will give a try. I would really like to have something like Realm/Autheticator where anybody can customize the Tomcat Provider the way they want... Regards, -- Jeanfrancois > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
