Re: Package Protection: which one?

[Jean-Francois Arcand]

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>