Allowing access to select few public objects (moved from Native forum)

Question

I am moving my posting from Java Forums > Fundamentals > Key Classes > Native forum to this one. Sorry for posting it on the wrong forum earlier. Before each reply I have added a lien for clarity.
Allowing access to select few public objects
Author: COOLNM Posts: 5 Registered: 12/21/05
Dec 21, 2005 9:59 AM
I am developing a java application. I need to provide some scripting support (using Jython or Rhino) to my application so that the user can better use my application. Now the problem is I just want a select few public objects to be accesible via scripts and not all public objects I have written internally. I read somewhere that class name and code obfuscation could be a option but not a full proof solution. Can anyone suggest how a full proof solution can be achieved? Would running the script interpreter in seperate JVM help (and propogate the calls to the original JVM) ? Would a custom class loader help? Please suggest.
Thanks,
COOLNM
Re: Allowing access to select few public objects
Author: IanSchneider Posts: 1,381 Registered: 10/26/00
Dec 21, 2005 10:14 AM (reply 1 of 10)
I read somewhere that class name and code obfuscation could be a option but not a full proof solution.Correct, someone could still can call obfuscated methods.
Would running the script interpreter in seperate JVM help (and propogate the calls to the original JVM) ?No.
Would a custom class loader help? Possibly depending upon how the interpreter dispatches calls.
Can anyone suggest how a full proof solution can be achieved?With jython, you could write custom PyObject subclasses (or general java facade classes) to expose only the methods you want to. The former technique allows more cool scripting functionality, the latter would presumably work in other interpreters. This would have to be done for every object you want to expose.
Alternatively, you could enable a SecurityManager and allow only trusted code to invoke yours.
Re: Allowing access to select few public objects
Author: COOLNM Posts: 5 Registered: 12/21/05
Dec 21, 2005 9:36 PM (reply 2 of 10)
I read somewhere that class name and codeobfuscation could be a option but not a full proof
solution.
Correct, someone could still can call obfuscated
methods.
Would running the script interpreter in seperate JVMhelp (and propogate the calls to the original JVM) ?
No.Could you please explain why this wouldn't work?
The plan is:
Let say I have 2 public objects A & B and I want the user to only use A via their scripts.
In JVM1: I use both A & B
In JVM2: I write a psuedo A and not B. For all the methods of A, I propogate the calls to JVM1 (I think this is achievable but not sure how)
The script interpreter runs on JVM2.
Now if the user tries to access A then the call would go to JVM1 but if he tries to access B then there is no B available in JVM2 so the user cant access B.
I know this method could be heavy as each call would have to go from JVM1 to JVM2.
By sepeate JVMs I mean seperate instance of java.
>
Would a custom class loader help? Possibly depending upon how the interpreter
dispatches calls.
Can anyone suggest how a full proof solution can beachieved?
With jython, you could write custom PyObject
subclasses (or general java facade classes) to expose
only the methods you want to. The former technique
allows more cool scripting functionality, the latter
would presumably work in other interpreters. This
would have to be done for every object you want to
expose.
Alternatively, you could enable a SecurityManager and
allow only trusted code to invoke yours.-----------------------------------------------------------------------------------------------------
Re: Allowing access to select few public objects
Author: allquixotic Posts: 12 Registered: 12/19/05
Dec 22, 2005 5:09 AM (reply 3 of 10)
RMI has a way for multiple JVMs to communicate programmatically; you could also use sockets on the loopback network device (localhost). These techniques are how mature Java products constrain their number of running instances to a finite number (usually 1), they terminate any starting JVM early in the initialization procedures of the main method if the "already-running test" indicates one is running.
If you use the networking method, you could basically read from a ServerSocket on the "executing" JVM, while the "scripting" JVM writes to a Socket. Then use reflection in the executing (server) side to determine if the method or object being referenced is one you want to expose. If not, do something -- like write back to the client that the method invocation was invalid. Reflection will slow down your code a lot though, so I don't recommend it for apps that already take up 50 megs or more of RAM ;)
Regards,
Sean
Re: Allowing access to select few public objects
Author: IanSchneider Posts: 1,381 Registered: 10/26/00
Dec 22, 2005 9:05 AM (reply 4 of 10)
Would running the script interpreter in seperate JVMhelp (and propogate the calls to the original JVM) ?
No.
Could you please explain why this wouldn't work?It could work. I said no because the other methods are better - easier to implement and vastly more performant without wasting resources.
Re: Allowing access to select few public objects
Author: COOLNM Posts: 5 Registered: 12/21/05
Dec 23, 2005 12:48 AM (reply 5 of 10)
Ya, the seperate JVM approach seems complex and might not be fully achievable.
Can someone give small code snippets on how the method level control be achieved using Java SecurityManager. Just a recap on what I am trying to achieve -
A & B are two public objects defined internally by my app.
I have to give the user of my app the ability to write some code. But only B
is to be exposed to client and not A.
Let say I have this code -
Object A = Interpreter.InitializeEngine(..);
A.executeFromUser(stdin);
The user mostly uses some scripting language, say Python and the Interpreter
is Jython. Now my Interpreter is capable of understanding calls to Java
objects from Python. If the user tries to access B via the scripts then it
should be allowed to do so but access to A should not be allowed via the
scripting language.
Thanks,
Neeraj
Re: Allowing access to select few public objects
Author: bschauwejava Posts: 721 Registered: 1/13/04
Dec 26, 2005 2:13 PM (reply 6 of 10)
What you probably want is to give the user access to an interface - not a class - that only exposes the methods that you want to expose.
This is the way all RMI APIs are exposed to client programs.
Re: Allowing access to select few public objects
Author: bschauwejava Posts: 721 Registered: 1/13/04
Dec 26, 2005 2:16 PM (reply 7 of 10)
Just one more comment. You haven't said very much about the runtime model of the scripting environment vs your java environment. How many processes do you expect to have running to make the system work? Are you expecting your java code to wind up in a jar file and get loaded by the Python process? Or are you planning on the java code executing in a separate process? If the latter, then RMI is probably your best bet.
Re: Allowing access to select few public objects
Author: COOLNM Posts: 5 Registered: 12/21/05
Dec 27, 2005 4:20 AM (reply 8 of 10)
I haven't finalized on the runtime model yet as the scripting security issue is still not resolved. But I am sure that the java app code would init and run the scripting code and not the other way round. The app is pretty huge with heavy UI. Ya, the java code would be wrapped in jars (but mostly not in a single jar as I dont want the jar to be too hefty).
Can someone comment on the use of SecurityManager in this case. My initial investigation shows that the objective on implementing method level security can't be implemented by this.
Re: Allowing access to select few public objects
Author: IanSchneider Posts: 1,381 Registered: 10/26/00
Dec 27, 2005 9:14 AM (reply 9 of 10)
My initial reply suggested writing a facade in java or by subclass PyObject. I highly recommend this path for ease of development, use, and runtime performance.
Given that you don't understand the basics of java security, I will recommend this again.
Re: Allowing access to select few public objects
Author: COOLNM Posts: 5 Registered: 12/21/05
Dec 27, 2005 11:33 PM (reply 10 of 10)
I have started investigating on facade in java and subclassing PyObject. But I am not sure how these would resolve the primary issue. Even if I use these and if the script writer knows that there is a public class, say XYZ in my app then he can always access that class directly skipping my subclassed PyObject or the Java facade. Or am I missing something here?

Answer 1

I have started investigating on facade in java and subclassing PyObject. But I am not sure
how these would resolve the primary issue. Even if I use these and if the script writer knows
that there is a public class, say XYZ in my app then he can always access that class directly
skipping my subclassed PyObject or the Java facade. Or am I missing something here?Presumably your objects are somehow connected to the application. Your user could do something like:
from com.foo import Player
p = Player()
p.setGold(Integer.MAX_VALUE)But of course the new Player object would not be part of the game. Now if you have some kind of static/singleton game state, then the malicious user could insert the Player into the game model...
The real trick lies in understanding how to setup the jython interpreter. If your interpreter classloader can only load facade classes (and system classes) then the client script could not load other classes. There is also a hook for the import keyword so you could disallow importing java classes. Each interpretor instance has the ability to setup the locals and globals for the session so you can insert live game objects.
I am only familiar with jythons internals, so this may or may not be applicable to rhino.