Re: RE: mx4j-Bugs-969175: Security and delegation

Bordet, Simone wrote:
>> Similarly, if jmxconnectorserver.jar wants to open up a 
>> JMXConnectorServer and grant remote users access to the 
>> DiskEraseMBean, then it better have the permissions to erase disks
>> itself.  Otherwise you have just allowed it to amplify its
>> permissions.
> 
> Again, I don't see how. The alternative implementation in MX4J allows
> you to grant SocketPermission to "jmxconnectorserver.jar", and
> FilePermission to principal "eraser" (codebase is the "special" jsr
> 160 domain). I could not be able to erase any file from
> "jmxconnectorserver.jar". That's why I tend to think the alternative
> security model is equivalent, or even better, wrt the current one.

OK, let me try to spell it out.

jmxconnectorserver.jar creates a connector server with a 
JMXAuthenticator that always returns a Subject containing "eraser". 
Then it, or an outside party, connects to the connector server through 
RMI and accesses the EraserMBean as "eraser".  Since you don't check the 
permissions of the creator of the connector server, this attempt works. 
  The fact that jmxconnectorserver.jar doesn't have FilePermission 
doesn't matter because you have discarded the information that 
jmxconnectorserver.jar created the connector server.  With the RI, we 
don't discard this information, and the attempt fails.

I don't know how to explain this any more clearly.  If it's still not 
clear, perhaps we could discuss it over the phone.

-- 
Éamonn


-------------------------------------------------------
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