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.
-- Jeanfrancois
>
>
>> I also thing that the permissions should be granted on apps,
>> not managers. The manager should check and have control over
>> the operation that it's doing. ( for example give only some applications
>> permissions to serialize the session in a file - that's probably a
>> bad example as using security manager for that is not the best
>> implementation, but I think you get my point ).
>>
>
> Persisting session data is the responsibility of the container not
> the web application. Session management/persistence should be completely
> transparent to the webapp including security policy permissions required
> for managing/persisting those sessions.
>
>
>> Costin
>>
>>
>> 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.
>>>
>>>
>>>>
>>>> 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,
>>>>>
>
> ----------------------------------------------------------------------
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
