Security Issues

Although Microsoft® J/Direct™ is a very powerful feature for standalone Java applications and trusted intranet Web applications, it is clearly too powerful to be used by normal Java applets on the Web. This section describes how J/Direct works with the security system of the Microsoft Win32 VM for Java to prevent untrusted code from abusing the power provided by J/Direct.

Trusted Versus Untrusted Classes

J/Direct divides all loaded Java classes into one of two categories:

1. Fully trusted (indicating maximum permissions).
2. Untrusted.

Only fully trusted classes are allowed to use J/Direct. A Java class is considered fully trusted if one of the following statements is true.

1. The class is digitally signed indicating full trust. An example of such a class would be a signed applet. To find out more about signing cabinet files, see the Creating and Using Cabinet Files article and the Signcode article in the Tools section of the Microsoft SDK for Java.
2. The class is installed on the target computer's CLASSPATH or installed by the package manager. A downloadable digitally signed library designed to be shared among multiple applets could meet this criterion.
3. The class is running as a non-browser application using the jview or the wjview application.

An unsigned applet on the Web, on the other hand, constitutes untrusted Java code.

Security Checkpoints for J/Direct Method Calls

The Microsoft VM applies security checks to J/Direct methods at three different times:

1. At link time.
2. Upon first invocation.
3. Upon every invocation.

An attempted J/Direct call takes place only if each of the three security checks passes or is explicitly disabled.

Security Checks at Link time

Linking is what occurs when one Java class invokes or accesses (using the Reflection API) a member of another class. At link time, the Microsoft VM checks to see whether the class being referenced is accessible and whether the arguments being passed are of the correct type and number. The class is considered accessible if it is in the same package or if it is declared public.

With the standard Java language, you are limited to a choice of two options for class accessibility: you can either declare a class public (so that anyone can link to it) or non-public (so that only classes in the same package can link to it). However, with Microsoft® Internet Explorer 4.0, there is now a third option. You can declare the class as "public for fully trusted callers only." You can declare any class with this type of accessibility, even if the class does not use J/Direct. To declare the class, place the following directive at the beginning of the class.

  /** @security(checkClassLinking=on) */

It is important to notice that this security check only prevents untrusted callers from directly calling the "protected" class. It does not prevent indirect calls. A third (fully trusted) class can forward a call from an untrusted caller to the "protected" class. However, there is a safeguard. The intermediate class must either be installed on the target computer's CLASSPATH, or it must be digitally signed for maximum trust and installed using the browser.

Security Checks upon First Invocation

The first invocation of a method is the first time the method is invoked from any caller. At this time, for each method marked with the native keyword, the Microsoft VM determines whether the method is a member of a fully trusted class. If it is not, a SecurityException is thrown that includes the message, "Only fully trusted classes can have native methods as members." Because this security check does not depend on the calling context, it only needs to be performed once. If it passes, the check does not take place on future invocations. There is no way to disable this security check.

Security Checks upon Every Invocation

This is the most stringent check available. On every call, the entire call stack is examined. If even one caller that is not fully-trusted is discovered on the call stack, a SecurityException is thrown. By default, all J/Direct methods perform this check. RNI methods do not perform this check because of backwards compatibility requirements. RNI was designed to allow easy porting from the original JDK 1.0 native interface, which did not offer this security check.

Although this security check offers maximum safety, Microsoft offers a way to disable it. The mechanism for disabling is provided because this stringent security check has two important side effects.

Possible Performance Degradation

This security check requires a scan of the entire call stack each time a J/Direct method is called. The performance degradation is most noticeable on trusted applets, which generally run with a security manager present. Applications, on the other hand, usually do not see a significant performance drop. This is due to the fact that J/Direct omits the call stack scan for applications that run without a security manager.

Inflexibility

This security mechanism forces the use of maximum permissions, even in cases where only one specific permission is required. For example, consider a trusted library that uses J/Direct to expose a single permission to untrusted applets in a safe way. It would be appropriate for this library to turn off the call time security check and perform its own security check for the specific permission.

The @security directive disables the per-invocation security check. Here is the syntax for this directive.

  /** @security(checkDllCalls=off) */

The @security directive applies to the entire class. Individual methods within a class cannot be tagged. The following example shows the placement of the @security directive.

  /** @security(checkDllCalls=off) */
  class FastJDirectMethods{
    /** @dll.import(...) */
    static native void func();
  }

Be aware of the fact that disabling this security check transfers responsibility for security from the Microsoft VM to you. Remember that even with this security check disabled, you will still have to digitally sign the class for maximum trust. If you decide to use this directive, be sure to take the following precautions:

• All J/Direct methods should be declared private.
• Any publicly accessible methods should never blindly pass caller arguments to J/Direct. You must take responsibility for ensuring that only valid arguments are passed to native code.
• Your class should expose no more capability than is required, and it should guard all access to these capabilities with the appropriate security checks.

Important Note Regarding Trusted Applets: Calls from within an applet's init, start, stop, or destroy methods may trigger a SecurityExceptionEx even if the applet is trusted. To avoid this situation, you should assert permissions by executing the following code.

  import com.ms.security.*;
    ...
  PolicyEngine.assertPermission(PermissionID.SYSTEM);

Security Checkpoints for J/Direct Structures

J/Direct also imposes security restrictions on classes that are marked using the @dll.struct compiler directive. Because structures only become unsafe when they are instantiated, these security checks are more efficient than the checks used for J/Direct methods. The following two security checks are performed on @dll.struct classes.

Load time	Classes marked with @dll.struct will load only if the context indicates full trust.
Link time	Code that is not fully trusted cannot link to classes declared using @dll.struct. The Microsoft VM will throw a NoClassDefFoundError if such an attempt is made.

Security and the com.ms.win32 Classes

For maximum security, the J/Direct methods defined in the com.ms.win32 package do perform the call stack check on each invocation. If you are using these classes for a Java application (running under jview or wjview), the performance overhead will be negligible. If you are using com.ms.win32 classes from a trusted class and require maximum performance, you should copy the required J/Direct declarations into your own classes and disable the per-invocation security check. See the Security Checks upon Every Invocation section for more information on disabling the per-invocation security check.