RE: RE: [Mx4j-user] RE: mx4j-Bugs-969175: Security and delegation

Hi, 

> I don't get you.  Usually, jmx-remote.jar (or whatever the 
> MX4J equivalent is) would be installed with AllPermission, 
> right?  Certainly when it lives in J2SE this is the case.  
> So, if I have a setup where this is the case, and where some 
> other code "creator" has SocketPermission but no other 
> permission, and where there is a Subject "eraser" that has 
> some other permissions, and where there is an MBean that 
> needs those permissions, then "creator" can invoke that MBean 
> without having the requisite permissions.  

Bah, I finally got it. It must be the age, or the lack of vacation :)

> Therefore the security model is violated.  It doesn't matter that this 
> might not be a very usual configuration.  It doesn't matter 
> that you *can* set things up securely. 
>   The point is that you are providing a library that could in 
> some circumstances allow people to subvert the security 
> model.  That is bad.
> 
> The fact that this is not the default behaviour does change 
> things.  If the new behaviour is only turned on if you set a 
> system property, and if you document the security risk of 
> setting the property, then there should not be a problem.  If 
> the new behaviour is turned on by supplying a property in the 
> environment Map when you create the connector server, then 
> there *is* a problem, since evil code can supply that 
> property.  I think that the SubjectDelegationPermission 
> solution is much cleaner than setting a system property.

I'm convinced.
I'll try to implement the SubjectDelegationPermission (the "Proposed Implementation") in the next days, and remove the current "Alternate Implementation".

Many thanks,

Simon


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id808&op=click