SDK 2.0 Security Samples Index

This sample demonstrates how to interact with the security system of Microsoft's VM for Java. The samples demonstrate three areas:
  1. performing security checks to protect access to resources from native code
  2. implementing custom capabilities, to protect resources not described by the stock permissions in com.ms.security.permissions
  3. assigning permissions to classes with custom class loaders

The 'com' and 'rni' samples demonstrate how to protect access to resources from native code. There are two ways to do this:

  1. initiating the check from the native code
  2. initiating the check from java code before calling the native method
The first mechanism has the advantage of always being safe regardless of who declares the java wrapper for the native code. It is easy for anyone to link to native code, COM or RNI, regardless of who authored it. If the native code is installed on the system, it is free game to fully trusted code. For this reason, initiating the security check from native code ensures complete safety.
However, calling a java method to perform a security check may incur a performance penalty, so some scenarios may prefer the second mechanism to prevent calls from normal native code from being penalized. COM code not written specifically to be called from java will prefer the second mechanism. The second mechanism has the disadvantage of being slightly less safe for the reason indicated above.
The 'com' sample demonstrates both mechanisms for COM calls, the 'rni' sample for RNI calls. J/Direct calls to native apis may have some measure of built-in security by optionally checking the stack for fully-trusted code at each invokation, but the same mechanisms demonstrated here may be applied to J/Direct as well to perform more specific types of security checks.

The 'custom' sample demonstrates custom capabilities. There are five things that need to be done to implement custom capabilities:

  1. define what the capability is to protect, and write an implementation of IPermission
  2. perform security checks for the custom capability in the code that accesses the resources that the capability is to protect
  3. if the capability is intended to be used for signing, write an implementation of IEncodablePermission.
  4. if a request object for access to the custom capability can provide additional details that may be useful to an auditor, write an implementation of ISecurityAuditInfo. Additional registry keys need to be set when the library is installed to indicate where the auditing messages are located.
  5. sign and package the custom capability classes as system code to be installed with the library. (Only system classes may define capabilities.)

The 'loader' sample constructs a class loader that assigns permissions to classes. Four things are demonstrated:

  1. decoding the permissions from pre-encoded form (.ini file or binary blob)
  2. manually building a set of permissions
  3. defining a class that has permissions
  4. inspecting the permissions of a class