Security

Overview

In general, an integrated Java/C++ solution is as secure as a pure C++ or pure Java solution. Some problems can arise if you're going to use Java platform security with your C++ application. In general, you will do this by configuring a security manager via the xmog_jvm_options::setSecurityManager(const char*) method and by configuring a security policy via the xmog_jvm_options::setSecurityPolicy(const char*) method.
Documenting how these two settings work would go too far, please consult the Java documentation for more details.

One problem that you encounter in a native application after you have configured a security manager is that the runtime will not initialize correctly when you load the JVM, at least it wouldn't unless you or we take special steps.
In order to make the Java/C++ interaction work transparently to a native developer, the
native runtime has to perform some operations that require privileges that are usually not granted by most security policies. To get things working, you can either explicitly grant the required privileges or you can use Codemesh's delegating security manager.

If you choose to go with Codemesh's delegating security manager (the default), it is installed as the system security manager in place of the one that you configured.
Codemesh's security manager will grant the required privileges and delegate all other checks to your configured security manager. What are the security consequences?

• there will be some granted privileges that were not configured by you
• there is a delegation in place, which makes this approach theoretically more attackable than the normal approach

On the plus side, this is much easier than trying to figure out, which privileges are required by the runtime and then having your application broken by the next version of our runtime because it requries an additional privilege.

There are of course run-modes that leave you entirely unprotected or with the above mentioned problems. If you choose to allow a pre-loaded JVM (for example because you're also using raw JNI in other places and can't be sure who gets to load the JVM), you might be running without a security manager or with an incorrectly configured one. If our runtime cannot initialize Java, you're on your own in getting things configured correctly.

An Example

So how do you configure Java security? You will almost invariably use the following snippet:

xmog_jvm_loader &    loader = xmog_jvm_loader::get_jvm_loader();
 
loader.setSecurityManager( "java.lang.SecurityManager" );
loader.setSecurityPolicy( "./app.policy" );
// the following line is redundant because this is the default
loader.setUseCodemeshSecurityManager( true );

The concrete privilege grants reside in the policy file, for example:

grant
{
    permission java.io.FilePermission "c:\\temp\\JC2.1\\XMOG\\staging\\examples-c++\\-", "read";
}

The above snippet will grant the application read privileges to all files in the specified directory and all its subdirectories. Incendentially, this is one of the permissions that you will have to grant your application codebase to be able to load classes from disk.

Runtime Privileges granted by the Codemesh security manager

grant
{
    permission java.util.PropertyPermission "java.protocol.handler.pkgs", "read,write";
    permission java.util.PropertyPermission "networkaddress.cache.ttl", "read";
    permission java.util.PropertyPermission "networkaddress.cache.negative.ttl", "read";
    permission java.util.PropertyPermission "sun.net.inetaddr.ttl", "read";
    permission java.util.PropertyPermission "user.dir", "read";
 
    permission java.security.SecurityPermission "getProperty.networkaddress.cache.ttl";
    permission java.security.SecurityPermission "getProperty.networkaddress.cache.negative.ttl";
 
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
};