Geir Magnusson Jr. wrote:
I meant execution context. Is there a clear boundary between code thats executing in the context of the VM and code that's executing in the context of the 'user' app?
Usually not, but it might be possible to emulate something similar using several classloaders or implement the necessary mechanisms in the default classloader. One similar example can be taken from Java applets. They are of course not allowed to load and execute native code, as the VM can't enforce any privilege checks on what the native code is doing, still though, the applet must of course be allowed to indirectly execute native code through the standard API, e.g. to gain allowed network access. In this case, the applet classes are loaded by a restricted classloader, which does not allow direct access to native code, while the standard API classes are loaded by a privileged classloader, which grants all privileges on "kernel" level and relies on the implementation of the classes to enforce the necessary security checks.
All this magic is however implemented using the mechanisms in the security manager and since an application must be allowed to use its own security manager, I don't see how it could be possible to prevent an application to break through such a protection either.
Tor
