Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS

[Glenn Nielsen]

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.
>>
>>
>>  [ ]  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)
>>
> 
> 
> 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:  

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS

[Remy Maucherat]

Costin Manolache wrote:
> Glenn Nielsen wrote:
> 
> 
>>
>>  [ ]  commit XML Policy source to jakarta-tomcat-4.0 HEAD
>>   and include it in future release of Tomcat 4.1.x
>>  [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)
>>
> 
> 
> 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.
> 
> 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.
> 
> 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 :-).
> 
> 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. 

I'd commit it as a module for now, and work from there. If we could 
avoid having to use Castor XML for parsing, that would be nice.
I understand your point of adding a new non-standard configuration file.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS

[Glenn Nielsen]

Remy Maucherat wrote:
> Costin Manolache wrote:
> 
>> Glenn Nielsen wrote:
>>
>>
>>> 
>>>  [ ]  commit XML Policy source to jakarta-tomcat-4.0 HEAD
>>>   and include it in future release of Tomcat 4.1.x
>>>  [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)
>>> 
>>
>>
>>
>> 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.
>>
>> 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.
>>
>> 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 :-).
>>
>> 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. 
> 
> 
> I'd commit it as a module for now, and work from there. 

I'm not sure what it means to commit something as a module to Tomcat.  The support
for XML policy files is only built in if you configure your build.properties
to do so.  Is that what a module means?

> If we could avoid having to use Castor XML for parsing, that would be nice.

I have used Castor for XML Schema support in several projects.
I just find that Castor makes use of XML Schemas much easier. And XML Schemas
are a significantly better solution than DTD's for validating XML.

Regards,

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS

[Jean-Francois Arcand]

ve 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?


[FYI]
JSR 115 
(http://jcp.org/aboutJava/communityprocess/first/jsr115/index.html) Java 
Authorization Contract for Container is in that direction (for 
expressing Web Permissions and for moving away from the *.policy file 
format). The spec doesn't say anything about the way policy file are 
represented (open the door to n
 




<!--
google_ad_client = "pub-7266757337600734";
google_alternate_ad_url = "http://www.mail-archive.com/blank.png";
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = "160x600_as";
google_ad_channel = "3243237953";
google_color_border = "CE9689";
google_color_bg = ["FF","ECE5DF"];
google_color_link = "006792";
google_color_url = "006792";
google_color_text = "00";
//-->







[VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS
Glenn Nielsen


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS
Costin Manolache


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS
Glenn Nielsen


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS
Jean-Francois Arcand


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS
Glenn Nielsen




Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS
Costin Manolache


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS
Glenn Nielsen


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS
Costin Manolache


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS
Glenn Nielsen


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code to CVS
Costin Manolache












Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS
Remy Maucherat


Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS
Glenn Nielsen









 






  
  





Reply via email to



  
  





 
 

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS

[Glenn Nielsen]

Jean-Francois Arcand wrote:
> 
> 
> Glenn Nielsen wrote:
> 
>> 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?
> 
> 
> 
> [FYI]
> JSR 115 
> (http://jcp.org/aboutJava/communityprocess/first/jsr115/index.html) Java 
> Authorization Contract for Container is in that direction (for 
> expressing Web Permissions and for moving away from the *.policy file 
> format). The spec doesn't say anything about the way policy file are 
> represented (open the door to new format). The main idea is to have a 
> pluggable Policy Provider. The Policy Provider could represent 
> permission the way it want, and have to publish it using the 
> WebPermission classes defined by the spec. I already made some change in 
> Tomcat 5 to allow the pluggability of a Provider
>
> If I understand properly (sorry I wasn't in the group 4 months ago), you 
> are trying to do something similar for all permission type (all 
> permissions described in the policy file). Castor is used to unmarshall 
> your XML policy statement to Permission objects. Is that correct? I 
> would be interested to see the code.
> 


Thanks for refering me to this JSR.  I quickly skimmed the spec, I will
have to read it in greater depth.

The primary focus of the JSR seems to be role based policies built on
top of JAAS. And that support for this is required in a J2EE 1.4 container
but optional for a J2EE 1.3 container.  So it could be back ported into Tomcat 4.

 From quickly skimming the spec it looks like it may address the core feature
which spurred my development of an XML based policy. The ability for a web
appliation to define its own security permissions.  But restricted to those
permissions which the container allows to be set (i.e. a sandbox).

The JSR is a great deal more complex than what I did but may meet the needs
I was trying to address.

Yes, Castor is used in the Tomcat build to generate the source for the java classes
which implement the XML Schema.  Then at runtime those generated classes use the
API in the castor xml jar.

A tarball with patches and new files for Tomcat 4 is available at:

http://duke.more.net/~glenn/tomcat4-xmlpolicy.tar.gz

if you would like to review this.

Regards,

Glenn





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS

[Glenn Nielsen]

Costin Manolache wrote:
> Glenn,
> 
> As a new feature, you need a majority of votes and at least 3 +1.
> My vote is -1 ( but is not a veto ). Only commits can be vetoed,
> and I'll probably do so if castor is used - all tomcat is using
> digester style for xml processing, and we have a proposal to 
> use JNDI to abstract XML processing. If each piece of tomcat
> start using another technology - maybe jaxb ? or any other 
> xml-to-java we'll end up with a huge mess.
> 
> I also strongly disagree with doing schema validations at 
> runtime ( i.e. on every run ), so if you really want validation
> it must be done only once ( and at each file modification ) or 
> be done by the config tools.

This code only does validation when the container is started or
when a web application context is reloaded.  The current implementation
using the standard policy file does the same thing only not with XML.

> 
> Yes, we have webdav bundled - aparently a majority of voters 
> believed it was a good idea. I think it isn't - and if someone
> propose to remove it and just recommend slide I'll be +1.
> But that's not a good argument for adding more.
> 

My only point is that the current policy is to bundle everything in
the Tomcat releases and not provide downloads for separate add on
modules.  We can discuss whether we want to change that policy.

> My major concerns are:
> - integration in a new config mechanism. If you don't like JNDI/JMX
> proposal, make another one - but we should have a consistent way of
> dealing with config ( as API ). 
> 
> - castor use. I like castor - and if a proposal is made to use 
> castor in all xml processing, I may be +0. But I'm strongly -1
> on using castor for policy, digester for server.xml and DOM for
> jasper.
> 

I agree with you in principal.  From having worked with the code
in Tomcat which uses the digester and the code which the admin
application uses for marshalling XML, the current Tomcat 4 code
for configuration management looks very "brute force".  I have
been thinking about how the current code works and whether
Castor would be a much simpler solution.

> - DTD - what are jboss or j2ee using for policy ? What other
> DTDs are in use for this ? XML is just a file format, if
> everyone uses a different DTD we're in a mess.
> 

I very much doubt if any servlet/J2EE containers use the same
configuration methods.  This is something the specs leave up to
the individual implementation.

> Again, I'm not vetoing ( I can't anyway ) the proposed new 
> feature, I'm just voting against ( proposals like this are
> majority votes - at least in my understanding )
> 
> Costin
> 
> 
> Glenn Nielsen wrote:
> 
> 
> 
>>>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 th

Re: [VOTE] commit new Tomcat 4 SecurityManager XML Policy code toCVS

[Glenn Nielsen]

Costin,

This is getting off topic from my original request.
(And I am partly responsible ;-)

My proposal is for adding thr XML policy code to the current
existing Tomcat 4 HEAD branch.

I would like to commit the code to CVS.  Building Tomcat with this
support is optional and can be left out of the current release builds.

The fact that it exists and is experimental can be documented in the security
manager HOW-TO documentation along with information on building Tomcat to
support this if someone desires to try it out.

Other possible changes to Tocmat we started discussing may be better
left for discussions of changes to the code base for Tomcat 5.

Will that be acceptable?

Regards,

Glenn

Costin Manolache wrote:
> Glenn Nielsen wrote:
> 
> 
>>This code only does validation when the container is started or
>>when a web application context is reloaded.  The current implementation
>>using the standard policy file does the same thing only not with XML.
> 
> 
> ??? 
> 
> Doing XML schema validation on each server start and webapp reload
> is what I disagree with. I think the config/deploy tools should use schema
> and validate as much as they wish - but at runtime it shouldn't be done
> ( except maybe once and on file change )
> 
> That applies to web.xml, tlds and any other xml file.
>  
> 
>>My only point is that the current policy is to bundle everything in
>>the Tomcat releases and not provide downloads for separate add on
>>modules.  We can discuss whether we want to change that policy.
> 
> 
> We don't 'bundle everything' - there are some features that were 
> aproved at some point. But I don't know of any policy of 
> 'bundle everything'.
> 
> We could create a 'tomcat+everything' distribution ( i.e. struts, velocity,
> axis, apache-soap, and so on ) - and it may be usefull. But a lot of
> people would like a smaller 'core' and more features moved in separate
> modules.  
> 
> In particular, for your policy.xml - that's much more 'core' than 
> webdav for example. And if it is integrated with the rest of the
> config - and everyone agrees that it's better to use the XML ( with
> a JMX/JNDI wrapper to integrate into the admin app ) - then we should
> deprecate the use of the old policy file. 
> 
> 
> 
>>>- castor use. I like castor - and if a proposal is made to use
>>>castor in all xml processing, I may be +0. But I'm strongly -1
>>>on using castor for policy, digester for server.xml and DOM for
>>>jasper.
>>>
>>
>>I agree with you in principal.  From having worked with the code
>>in Tomcat which uses the digester and the code which the admin
>>application uses for marshalling XML, the current Tomcat 4 code
>>for configuration management looks very "brute force".  I have
>>been thinking about how the current code works and whether
>>Castor would be a much simpler solution.
> 
> 
> If everyone agrees castor is a better solution - then we should
> use it. But we should do it consistently.
> 
> The current proposal is to use a JNDI frontent ( and abstract 
> XML out - i.e. support directory servers and other storages ). That
> means the current direct XML reading/writing will be changed. 
> 
> 
> 
>>>- DTD - what are jboss or j2ee using for policy ? What other
>>>DTDs are in use for this ? XML is just a file format, if
>>>everyone uses a different DTD we're in a mess.
>>>
>>
>>I very much doubt if any servlet/J2EE containers use the same
>>configuration methods.  This is something the specs leave up to
>>the individual implementation.
> 
> 
> The whole value of XML is on commons DTDs and schemas. WEB.XML is 
> such a standard - and each container supports it. 
> 
> In many cases it is impossible to get a standard DTD ( server.xml for
> example ). But for policy ( or the xml used in modeler ) - there are 
> enough common things. 
> 
> If j2ee or jboss or some other app is using an xml policy file - I see no 
> reason why we couldn't use the same DTD but invent our own.   
> 
> Costin
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: