Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 86751 invoked from network); 16 Oct 2002 17:42:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Oct 2002 17:42:35 -0000 Received: (qmail 28416 invoked by uid 97); 16 Oct 2002 17:37:43 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 28114 invoked by uid 97); 16 Oct 2002 17:37:42 -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 28039 invoked by uid 98); 16 Oct 2002 17:37:38 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DADA3AE.4010500@mail.more.net> Date: Wed, 16 Oct 2002 12:36:46 -0500 From: Glenn Nielsen Reply-To: glenn@mail.more.net Organization: MOREnet User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.0.1) Gecko/20020725 Netscape/7.0 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> <3DAD81A3.2000005@apache.org> Content-Type: text/plain; charset=us-ascii; 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 Jean-Francois Arcand wrote: > > > 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. > How Session's are persisted is up to the container, not in the spec. Tomcat has in o.a.c.session two different Store's, a file Store and s store which uses JDBC. Plus an administrator could write their own custom Manager/Store and configure it in server.xml. In my testing of Tomcat with a very strict security policy and the default session manager that doPrivileged() was needed. If it hadn't been needed, it wouldn't be there. It would definitely be needed if JDBCStore was used. PersistentManagerBase() can swap in/out sessions as needed with the Store. This would fail if the doPrivileged() block were not there and a web app tried to get a Session which had been swapped out to disk or db. >> >> >> 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. > All the doPrivileged call does is reset what ProtectionDomains are checked by the AccessController checkPermissions. Yes, there is overhead when calling doPrivileged(), but there are times when this is needed, and this is one of them. In regards to the size of the block of code executed within a doPrivileged() that is from the standpoint of security, i.e. all code now being executed has more permissions granted so you have to make sure that the code which triggered the doPrivileged() can't bypass security. That is not so in this case. > 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? > No, every manager is not granted whatever they want. The Manager/Store which come with Tomcat are granted whatever permissions are granted to catalina.jar. A custom Manager/Store is allowed whatever permissions were granted to it in the catalina.policy for it's codeBase. Still -1 for changing/removing the doPrivileged() Regards, Glenn ---------------------------------------------------------------------- Glenn Nielsen glenn@more.net | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | ---------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: