Comments intermixed below. Costin Manolache wrote: > Glenn Nielsen wrote: > > >>Tomcat SecurityManager XML Policy configuration >>----------------------------------------------- >> >>I have finished implementing support within Tomcat for using XML based >>security policy >>files. This was proposed and discussed on the list back 3-4 months ago. >> >>I would like to commit this to the jakarta-tomcat-4.0 CVS HEAD and have it >>included in future 4.1.x releases. Initially it could be listed as either >>experimental, alpha, or beta. Whichever we decide. >> >>- This new feature is fully backward compatible with current methods >> of using catalina.policy. Use of the XML based policy is >> invoked by using the -security-xml startup option instead of -security. >> >>- Catalina can be compiled without support for use of an XML policy. >> To build with support for an XML policy the Castor XML Schema >> jar file and the Jakarta ORO jar files must both be present. >> >> http://castor.exolab.org/ >> http://jakarta.apache.org/oro/ >> >>Here is a URL to the updated Security Manager HOW-TO which documents >>the new XML Policy features. >> >> > > >http://duke.more.net/~glenn/tomcat-docs/security-manager-howto.html#Optional%20XML%20Policy%20Configuration > >>Please review the above before voting. >> >>If you are interested in looking at the code before I commit I could >>create a patch file with all the changes against jakarta-tomcat-4.0 >>CVS HEAD and make it available. Just let me know. >> >>Here is a ballot. I would prefer not creating a Tomcat 4.2 development >>branch yet, that just adds more CVS branches to commit bug fixes to. >> >><ballot> >> [ ] commit XML Policy source to jakarta-tomcat-4.0 HEAD >> and include it in future release of Tomcat 4.1.x >> [ ] commit to CVS but don't add to the next release >> [ ] create a Tomcat 4.2 development branch and commit there (Ugh!) >> [ ] -1 Don't commit to CVS (Please explain why) >></ballot> > > > I'm -0 on adding yet another config file - WEB-INF/policy.xml is also > strange as webapps ( which shouldn't be trusted ) get to set the security > policy. This is very tricky - and will need a lot of review. >
Using Tomcat with the XML based policy file is optional, so it is another config file only if it is being used. And I tried to provide good documentation on how to use it. /WEB-INF/policy.xml works. The code is pretty straightforward. Only those permissions which the global policy.xml allow can be configured in the web app. This is done using the Permissions.implies() method. And the web app can only configure permissions for code sources that exist within its context directory. I plan on putting this into production and I am very paranoid when it comes to security. > However I'm -1 on adding deps on castor and doing schema validations - at > least at this stage ( and after the experience we had with web.xml > schemas ). Castor is very nice, but is also a big thing. > What experience was it that "we" had with web.xml schemas? I have used Castor on other projects. It does more than validation, it is also used to generate Java source code when Tomcat is built for the XML Schema elements. Tomcat on a production system already takes up a huge amount of resources (memory), I don't think the extra memory required by Castor classes would be noticed. And those resources would only get used if you use the XML based policy files. > The current policy file is standard and likely to be understood by tools. > XML may be in theory easier, however I doubt too many tools understand > this particular DTD. So I prefer keeping the current file format as default, > at least until a standard security policy DTD is defined ( standard == > we're not the only ones using it :-). > The current policy file also has its limitations. This new policy.xml is more intutitive to configure. Any tool which understands XML can be used to configure your XML Policy files, such as XML Spy. The JVM itself anticipated a need for alternative application specific Policy implementations and has the hooks for doing it. Are you aware of anyone working on a new standard? Is there a JSR? > If you need this functionality - I would propose making it a separate > module ( sort of add-on to tomcat ), instead of bundling it with tomcat > by default. > This isn't just for me. The type of features the XML Policy code add have been requested in discussions I have had about the Java SecurityManager at ApacheCon and JavaOne. There currently are no official Tomcat add on modules. Everything comes bundled with it. There have been discussions about this, the end result being that it is easier for the user if everything is bundled together. There are a number of Tomcat features that I don't use such as webdav, ssi, and cgi to name a few. I just remove those things I don't need. If you don't need to use the policy based XML, don't use it. Regards, Glenn -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
