Java Security

This chapter covers the Java security implemented in JNode. This involves the security manager, access controller and privileged actions.
It does not involve user management.

The Java security in JNode is an implementation of the standard Java security API. This means that permissions are checked against an AccessControlContext which contains ProtectionDomain's. See the Security Architecture for more information.

In JNode the security manager is always on. This ensures that permissions are always checked.
The security manager (or better the AccessController) executes the security policy implemented by JNodePolicy. This policy is an implementation of the standard java.security.Policy class.
This policy contains some static permissions (mainly for access to certain system properties) and handles dynamic (plugin) permissions.

The dynamic permissions are plugin based. Every plugin may request certain permissions. The Policy implementation decides if these permissions are granted to the plugin.

To request permissions for a plugin, add an extension to the plugin-descriptor on connected to the "org.jnode.security.permission" extension-point.
This extension has the following structure:

<permission class="..." name="..." actions="..."/>
...

class The full classname of the permission. e.g. "java.util.PropertyPermission"
name The name of the permission. This attribute is permission class dependent. e.g. "os.name"
actions The actions of the permission. This attribute is permission class dependent. e.g. "read"

Multiple permission's can be added to a single extension.

If you need specific permissions, make sure to run that code in a PrivilegedAction. Besides you're own actions, the following standard PrivilegedAction's are available:

gnu.java.security.actions.GetPropertyAction Wraps System.getProperty
gnu.java.security.actions.GetIntegerAction Wraps Integer.getInteger
gnu.java.security.actions.GetBooleanAction Wraps Boolean.getBoolean
gnu.java.security.actions.GetPolicyAction Wraps Policy.getPolicy
gnu.java.security.actions.InvokeAction Wraps Method.invoke
‹ Garbage collectionupMulti-threading ›

SecurityExceptions and workarounds

Submitted by Stephen Crawley on Thu, 03/26/2009 - 06:08.

It is not uncommon to run into unexpected SecurityExceptions when adding new code. Often the exceptions are complaining about things that probably should be allowed anyway. (For example, at the time of writing this comment, the standard permissions do not allow a command to read the System properties.) Clearly, we need to review the permissions granted "as standard" at some point.

In the meantime, there are two possible workarounds for SecurityExceptions.

The "good" workaround is to add a <permission class="..." name="..." actions="..."/> element to the relevant plugin descriptor as described above. In addition to making your code work, this documents the fact that something in the plugin needs (or to be more accurate may need) special permissions.

The (IMO) "bad" workaround is to build JNode with security disabled. In the "jnode.properties" file, uncomment the line that says "#jnode.security.enabled=false", then do a full rebuild. So why do I think this is a bad idea? Simply because (if you are like me) you will occasionally to forget that you have disabled security and check in code that breaks when run on JNode with security enabled. Still, if you don't mind causing the occasional regression ...