Setting security manager

Question

Hi,
I have a typical requirement which asks me to have a security manager which applies to only a part of the code and not to the whole code. I will try to explain it.
Lets say I have a class A which does something (may be it accesses files, open socket connections over network etc etc). This class A is a sort of trusted class and is allowed to do everything. Now suppose this class is built in such a manner that it can load another class B at runtime which could be any class written by any third party. So what exactly class B will do cannot be predicted because it is a third party class. Now what I want is to set a security manager only for class B that will prevent it to do any nasty things like accessing file system, shutting down vm etc. . Please note that class A can do all these things but class B should not be allowed to do these. If class B tries to do any of those things then security exception should be thrown.
Hope I made my point clear.
Please note that I am not talking of Applets but complete application so pls dont forward any replies which applies to applets.
Can anyone help pls........
regards.

Answer 1

Hey guys,
crack_it:
If you would rather dismiss the (A)pplication (P)rogramming (I)nterface then go ahead. No disrespect to the folks at O'Reilly, but reading the API is as good as hearing it from the horses mouth. If you could humour me, just test what the API says.
I can't remember if we discussed it somewhere at some point, but I am under the impression you are locking-down you application designed in a plugin-architecture.
If this is true, you simply need to specify two entries in your policy: one for your code in app_home/lib; one for third-party code in app_home/plugins. How you load these classes are irrelevant.
As for detecting which classes trigger security checks, as mmhuda says, you can access the execution stack through the Thread class. You can retrieve information on the calling class and its method which made the call. These 'calls' are stacked i.e. most recent first. You may need to skip 3 or 4 frames (StackTraceElements) which represent the calls to access the stack information. It is troublesome. I recently implemented a similar method wihtin my Policy implementation to prevent it from being wrapped and exploited by other bogus policy implementations. I have a lookup of class.method --> class.method strings that represent permitted calls. All you would need to do is implement a lookup mapping class or class.method --> Permission or Permissions (PermissionCollection) containing what the class can do, and check against them.
Now I have stated it, I am even more convinced; you are simply reimplementing the security infrastructure,or rather, shifting the function of the Policy and AccessController to your XxxxSecurityManager. Perhaps a waste of effort.
mmhuda:
Do not confuse terms; a class can be loaded and not in the execution stack - I wouldn't be surprised if a loaded class spends 99.99% of its life sitting idle off the stack. The stack represents a 'chain' of method calls for a particular Thread. It does not represent all the loaded classes in the JVM, otherwise the stack would be 100's of frames deep.
Warm regards,
D