Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 79742 invoked from network); 24 Oct 2002 21:54:51 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 24 Oct 2002 21:54:51 -0000 Received: (qmail 2793 invoked by uid 97); 24 Oct 2002 21:55:39 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 2777 invoked by uid 97); 24 Oct 2002 21:55:38 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 2765 invoked by uid 98); 24 Oct 2002 21:55:37 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DB86C2E.6050606@apache.org> Date: Thu, 24 Oct 2002 17:54:54 -0400 From: Jean-Francois Arcand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: Package Protection: which one? References: <3DB80C9D.7080707@apache.org> <3DB8146A.4000305@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > > For additional commands, e-mail: > > > -- To unsubscribe, e-mail: For additional commands, e-mail: