RE: mx4j-Bugs-969175: Security and delegation

Hi, 

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

> >> Note that the authenticated subject from a connection does not need
> >> to have any permissions other than SubjectDelegatePermission and 
> >> possibly some JMX permissions.  It doesn't need to have
> >> FilePermission or whatever, provided that remotely-invoked
> >> operations that need those permissions do them through a delegated
> >> Subject.  However 1 does need to have these permissions.
> > 
> > True. The corollary is that "server.jar" needs to be granted all
> > permissions needed by the application. I'm not sure this is good.
> 
> I do not see what is wrong with it.  More accurately, I do 
> not see how 
> it can be any different, with the RMI connector as specified, and not 
> open up a security hole.

As above, I don't see the security hole.

If you don't trust "jmxconnectorserver.jar", then you suppose that this jar is doing something wrong. For example, it always authenticate users without checking passwords (which is - if I have correctly understood - the attack you were talking).
In JSR 160 implementation (both RJMXRI and MX4J), when an incoming call arrives with subject "pirate", the implementation goes in the policy file and sees that principal "pirate" has no permissions.
If principal "trusted" comes along, the policy file specifies AllPermission.

The question is: why should I grant "jmxconnectorserver.jar" AllPermission just because principal "trusted" requires it ?
Or: why I cannot see the security hole ? If you have the time to code it, will be great. I tried without success.

Do you agree that if there are no security holes, the alternative model is more powerful ?

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