Re: demo site

Sounds good.  I'll probably get around to this on Sunday, unless
somebody else comes up with something to change our current thinking.


Bordet, Simone wrote:
> Hi,
> 
> 
>>>I think the architecture can be:
>>>
>>>JVM 1
>>>The web container and the JSR 160 client
>>>No security manager
>>>web.xml configured to restrict access to resources, or to 
>>
>>force login.
>>
>>Requiring a login defeats the purpose of a demo site serving 
>>the public at large.  Perhaps you mean login for privileged 
>>functions like administration?
> 
> 
> I agree with you that login should not be required.
> As for admin purposes, that may be the case, even if then it becomes a fairly complicated web app.
> I just mentioned it above as an example of what you can do in JVM1 for security.
> We can for example provide a dummy login to show that the JMX gui can be easily restricted only to certain users.
> 
> 
>>For the primary function, manipulating MBeans, I can't think 
>>of how we could do any meaningful restrictions in web.xml, 
>>since our purpose is for anonymous users to be able to use 
>>these functions according to the restrictions imposed by Jmx 
>>server running in JVM 2.  Maybe I'm missing something?
> 
> 
> No misses, you are correct.
> 
> 
>>>JVM 2
>>>JSR 160 connector server
>>>Running under security manager
>>>security file restrict operations as needed.
>>
>>This is where we would restrict to a set of classes and other 
>>resources, correct?  (As I said above, I think that this 
>>provides all the protection needed.  If Jmx client-side 
>>restrictions also needed, please explain why).
> 
> 
> Correct, in JVM2 you allow only safe operations for your server. You disallow registering MBeans you don't trust, classloader MBeans, you disallow MBeans to read/write/execute on disk and so on.
> 
> JMX client side is totally hidden from users. 
> In theory there is some possibility to load a nasty JSR 160 provider (one that does not connect to the server but erases your HD), but only if you can set system properties (which you cannot do from a browser).
> I cannot think of a security hole from the jsr 160 client: what the web application will do is convert a HTTP GET/POST into a method call on a MBeanServerConnection object. That call will have effect only on JVM2, which is secured.
> This first go seems clean to me. 
> 
> Simon

-- 
ICF:  703-934-3692       Cell:  703-944-9317


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click