tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Francois Arcand <jfarc...@apache.org>
Subject Re: [Proposal] Having a Tomcat.security file.
Date Wed, 16 Oct 2002 21:39:29 GMT


Glenn Nielsen wrote:

> Jean-Francois Arcand wrote:
>
>> Hi,
>>
>> I've re-factored Catalina.java and CatalinaService.java and merge the 
>> security code into a single class: o.a.c.security.SecurityConfig. 
>> This class will manage all the package access/definition security 
>> properties.
>>
>
> Works for me!  You might consider moving 
> o.a.c.startup.SecurityClassLoad.java
> into o.a.c.security also since it is directly related to use of the
> SecurityManager.

That's a good idea. I will do that.

>
>
> Is this change just in Tomcat 5?

Yes, but I can port easily the change in Tomcat 4 also.

>
>
>> Actually, the list of package access/definition are harcoded in that 
>> class. I would like to propose we move this package list into a 
>> Tomcat.security file following the J2SE format (see below). This way 
>> if people needs accesses to a package, they will have the opportunity 
>> to do it with having to recompile Catalina.
>>
>
> If someone needs access to a restricted package they can grant the 
> appropriate
> RuntimePermission in their catalina.policy.  What packages need 
> restrictions
> rarely change. Moving the list of packages into a Global variable 
> would make it
> easier to change these the rare times we need to.  But I am -1 for adding
> a new config file just for this.  If somone has their own packages 
> which they
> feel need restrictions they can always update their own 
> $JAVA_HOME/jre/lib/security/java.security file.

o.a.c.security.SecurityConfig currently contains 2 global variables: 
PACKAGE_ACCESS and PACKAGE_DEFINITION. :-)
OK then I will leave it like that. I would consider adding a section to 
the Secutity-Manager HOW To to explain how to change those settings.

>
>
>> Righ now, some Watchdog tests are failling because they need accesses 
>> to o.a.t.util, and yesterday, we have started protecting this package.
>>
>
> Either grant the appropriate permissions where needed in catalina.policy

Ya, but I have to give access to the entire package. No problem for 
Watchdog, but I prefer the public folder. This way we don't need to 
change the catalina.policy file everytime we run Watchdog.

>
> or wrap more code with doPrivileged() in catalina methods which need it.

>
>
> There are classes or sub packages in org.apache.tomcat.* which need
> to be restricted.  But are the classes which are causing the failure
> ones which are sensitive from a security standpoint. 

util.http.ValuesEnumerator
util.http.NamesEnumerator

I don't think they are sensitive. We have the same issue with 
o.a.c.u.ParameterMap

> If not, perhaps
> those classes should be moved into a different package which is not
> restricted.  

+1 I think we should consider having a package in each catalina project 
where we expose classes to webapp. The easiest way be to create a 
"publicClasses" package under each sub-project. Since there is not a lot 
of classes like that, it should be easy ( I can do it). Any 
recommendation for the package name?


> If this isn't workable then either grant the appropriate
> permissions where needed in catalina.policy or wrap more code with
> doPrivileged() in catalina methods which need it.

I prefer the "public" package instead of doPrivilege block.

>
>
> SecurityManager related changes and subsequent testing with the default
> policy file and a very strict policy file can be a very painstaking 
> process.
> I am happy to more developers getting involved in this area of Tomcat. 
> :-)
>
> Regards,

;-)

Thanks,

-- Jeanfrancois

>
>
> Glenn
>
> ----------------------------------------------------------------------
> Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
> MOREnet System Programming               |  * if iz ina coment.      |
> Missouri Research and Education Network  |  */                       |
> ----------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:   
> <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:tomcat-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message