Hello Jean and company, Funny you bring up this issue. I opened a Tomcat Bugzilla (#12968) to suggest protecting o.a.c/o.a.j but Glenn didn't agree with my intentions. You can refer to the Bugzilla description thread for details:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12968 I concur that protecting server-specific packages such as o.a.c and o.a.j is the way to go, since they are intended to be inaccessible by untrusted code. Regards, -Eddie --- Jean-Francois Arcand <[EMAIL PROTECTED]> wrote: > > > 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 __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
