Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 23049 invoked from network); 16 Oct 2002 15:11:28 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Oct 2002 15:11:28 -0000 Received: (qmail 26956 invoked by uid 97); 16 Oct 2002 15:12:11 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 26937 invoked by uid 97); 16 Oct 2002 15:12:10 -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 26920 invoked by uid 98); 16 Oct 2002 15:12:10 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DAD81A3.2000005@apache.org> Date: Wed, 16 Oct 2002 11:11:31 -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: [Security Audit] CoyoteRequest.doGetSession References: <3DAC8BAE.8070507@apache.org> <3DAD7410.8050609@mail.more.net> 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 Glenn Nielsen wrote: > The doPrivileged() for getting a session is in the CoyoteRequest > public getSession() > method which is implemented as required by ServletRequest and > HttpServletRequest. I'm unable to find the information in the spec. Can you point me to the section where the discuss the required privilege? My understanding is the doPrivilege block is needed only if you want to serialize/store the session. If you don't, then you don't need it. If you run Tomcat as it is right now (with the security manager), then you don't need the extra call. > > > The getSession() can be called by a web application. The > doPrivileged() block would > be required to exist either where it currently is or in each > individual implementation > of Manager/Store. If it wasn't there getting a session would fail if > the web app > were not granted the necessary permissions. Permissions I would not > want to grant to it. Not in the current implementation. Since the default Manager do not need any special permission, the doPrivilege block is not required. > > > IMHO it is best left where it is. If someone were to implement a > custom Manager/Store > then the permissions allowed at that point would be the intersection > of those permissions > granted to catalina and those granted to the codeBase for the custom > Manager/Store. > So you still have your fine grained control of security policies. > That is how it should work. Well, every Manager have a large set of permissions granted by default. I personnaly prefer limitting the permission set instead of granting everything (like the current implementation). Also, the doPrivilege block (as implemented right now) do not contains anything that require special permissions. The doPrivilege block is a performance penalty, and the block is way too big ( for security reasons ). See http://java.sun.com/products/jdk/1.2/docs/guide/security/doprivileged.html for more info. Right now, every Manager are granted by default whatever they want. If I want to denied ManagerA file permissions, I have no way to do it right now...right? > > > -1 for changing/removing the doPrivileged() Other voices? > > > Regards, > > Glenn Thanks, -- Jeanfrancois > > > Jean-Francois Arcand wrote: > >> Hi, >> >> In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a >> doPrivilege block that grant the doGetSession method. This method >> delegate the logic to the o.a.c.Manager instance. A Manager can (but >> it's not required) uses a o.a.c.Store object . The Manager and the >> Store object may need special privileges when handling session >> persistance (see o.a.c.session.FileStore for an example). >> >> I would recommend we remove the doPrivilege block from CoyoteRequest >> and delegate the doPrivilege call to the Manager (or the Store) >> instance. That will allow better fine grained security check. Only >> the required operations should be granted (right now every Manager is >> granted -> so every Store instance!). As an example, >> o.a.c.session.FileStore does not contains any security checks in its >> current implementation, and IMO, it should. >> >> The contract between the Manager and CoyoteRequest will have to be >> documented somewhere since Manager written for Tomcat 4 may no longer >> works. The catalina.policy file can then be used to give special >> privileges to ManagerX, but not to ManagerY (same for Store instance >> or whatever objects is used), based on codebase. >> >> Any recommendations/objections to the modification? >> >> Thanks, >> >> -- Jeanfrancois >> >> P.S Right now, if you run Tomcat with the default Security manager, >> the doPrivilege block is useless. For performance reason, we should >> avoid this call. >> >> >> -- >> To unsubscribe, e-mail: >> >> For additional commands, e-mail: >> > > > > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > -- To unsubscribe, e-mail: For additional commands, e-mail: