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 [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]>
