tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Francois Arcand <jfarc...@apache.org>
Subject Re: [Security Audit] CoyoteRequest.doGetSession
Date Fri, 18 Oct 2002 21:50:26 GMT
OK, I have committed the change, do testing, and try to hack the code I 
just wrote. Of course, more testing will be appreciated :-)

-- Jeanfrancois



Glenn Nielsen wrote:

> Jean-Francois Arcand wrote:
>
>>
>>
>> Glenn Nielsen wrote:
>>
>>> Costin Manolache wrote:
>>>
>>>> I'm in the middle on this one - but I would vote for Jean-Francois 
>>>> proposal.
>>>>
>>>> Glen is right, it is possible to restrict individual managers
>>>> using the policy.
>>>> However as geenral programming it is better to keep the
>>>> doPrivileged block as small as possible - and have each individual 
>>>> manager that needs to change the permission context
>>>> do that for the specific areas where this is needed, instead
>>>> of a global aproach.
>>>
>>>
>>>
>>>
>>> In general I agree, keeping the amount of code within a doPrivileged()
>>> block to a minimum is a good practice.  That makes it less likely that
>>> the code which calls a method which uses doPrivileged can compromise 
>>> security.
>>> That is not the case for getSession() where the only thing passed to the
>>> method is a boolean for create and the Manager gets the JSESSIONID 
>>> cookie
>>> from the request.
>>>
>>> Removing doPrivileged() from where it currently is will force alot of
>>> other work to be done.  And will then require anyone who implements a
>>> custom Manager/Store to wrap their code in doPrivileged() also.
>>>
>>> I don't see any security risks from the current implemenation, so 
>>> why change it?
>>> If you can show me an exploit that this change would fix I would be 
>>> all for it.
>>
>>
>>
>> Eum...why waiting for a security issue (joke: we are not Microsoft 
>> ;-) ). Spending time trying to demonstrate a security hole will take 
>> as much time as reducing the doPrivilege block. I understand your 
>> point but still, I consider the doPrivilege block too large. And 
>> still, when Tomcat is used as it is (with the default 
>> SecurityManager), the doPrivilege block is *not* required. For a lot 
>> of Tomcat users, we are forcing a doPrivilege block.....
>>
>> Correct me if I'm wrong, but only JDBCStore and FileStore needs to be 
>> changed.  I volonteer to make the extra work.
>>
>
> It isn't the size of the block of code that matters...
> Its how the code within that block could pose a security risk.
>
> From a security standpoint I don't see any possible exploits.  There 
> may be
> a slight performance improvement for those requests where a session is 
> used
> by moving the doPrivileged out of the critical path. From just a 
> performance
> perspective I would want to profile Tomcat to determine where efforts 
> could
> be best spent to improve performance. Then spend time on the biggest 
> bottleneck
> to performance found rather than on this.
>
> It will require that the documentation for how to write a Manager/Store
> be updated to discuss this issue.
>
> It will also require alot of testing to make sure that you find _all_ the
> places where a doPrivileged is needed.  That means trying all the 
> Manager/Store
> implementations which come with Tomcat and trying different 
> configuration options.
>
> Sounds like alot of work to me. I know I don't have the time to make a 
> change
> like this for the minimal benefit I see.
>
> But if you have the time and want to implement this, go ahead, its 
> your itch. :-)
>
> Regards,
>
> Glenn
>
>
> --
> 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>


Mime
View raw message