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: Package Protection: which one?
Date Thu, 24 Oct 2002 21:54:54 GMT


Remy Maucherat wrote:

> Jean-Francois Arcand wrote:
>
>> Hi,
>>
>> testing package protection, I have come to the following conclusion:
>>
>> Packages that we can protect against access
>> ----------------------------------------------
>> o.a.catalina
>> o.a.jasper
>> o.a.jsp
>> o.a.jk
>>
>> Packages that we can protect against definition
>> ----------------------------------------------
>> o.a.catalina
>> o.a.jasper
>> o.a.jsp
>> o.a.jk
>> o.a.coyote
>>
>> Package that could be protected, but need to change:
>> -------------------------------------------------------
>> o.a.naming
>
>
> Naming is designed to be secure as is, and shouldn't need protection.
>
>>
>> o.a.coyote
>
>
> The implementations are protected by facades which have no useful 
> methods for an attacker.
>
>>
>> o.a.tomcat.util
>
>
> I think this is safe too.
>
>>
>> If we decide to fully protect o.a.coyote, that means that every calls to
>> CoyoteRequestFacade and CoyoteResponseFacade will need to runs under a
>> doPrivilege blocks (every call that use o.a.tomcat.util). Then
>> o.a.tomcat.util could be protected (only if o.a.coyote is).
>>
>> I made a wrong recommendation last week when I said that o.a.coyote can
>> be protected (rule #1 test using the jakarta workspace, not with  your
>> local workspace). Testing with basic servlet prove me the contrary (see
>> 4.1.13 release notes....guilty!). I've committed in both Tomcat 4 and 5
>> the proper protection configuration.
>>
>> I would like to have recommendations based on which package should be
>> protected. Based on the list I will audit package that stay unprotected.
>
>
> I don't think being paranoid would be very useful given that there are 
> facades which are supposed to get the job done. Of course, I'm not the 
> one making the audit, so I don't know for sure.
>
> Remy

Well, maybe I paranoid (OK I paranoid).....but I would prefer protecting 
all packages and implement the appropriate doPrivileged block. This way 
we avoid situations like:

(1) a new committer add a class to an unprotected package and open a 
security hole. A good example is, in Tomcat 4, o.a.c.util is not 
protected because there is no sensitive classes (right Glenn?). But 
let's say in two year we need to add a class and actual committers are 
gone because their stock options make them rich (OK I paranoid again :-) )
(2) a hacker breaks a facade and accesses some confidential data.

Actually, (2) seems the easiest way to do something bad (and from SUN 
security group, the most frequent security issue). I must admit that 
since I'm working on the audit (3 weeks), I did not found any facade 
that contains a potientally security issues...but IMBW, I'm not an 
hacker.....  

I would like a decision to protect/not protect a package as soon as 
possible, since I will not audit a package that is protected (I will 
just add the appropriate doPrivilege block). And not protecting a 
package make my life easier since I don't have to implement doPrivileged 
blocks and try to find every situation when a doPrivileged block is 
required....Should we vote?

-- Jeanfrancois

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