Microsoft SDK for Java

J/Direct Security Issues

This section describes how Microsoft® J/Direct™ works with the security system of the Microsoft virtual machine (Microsoft VM) to prevent possible problems caused by untrusted code.

Trusted versus Untrusted Classes

J/Direct divides all loaded Java classes into trusted and 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:

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:

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 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 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 (anyone can link to it) or non-public (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 only fully trusted callers. 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 as shown in the following example.

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

Note   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, a safeguard exists. The intermediate class must either be installed on the target computer's class path 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 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 needs to be performed only 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

Security checks upon every invocation 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.

Raw Native Interface (RNI) methods do not perform this check upon every invocation because of backward 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, it has two important side effects as shown in the following table. Therefore, Microsoft offers a way to disable security checks upon every invocation.

Side Effects of the Security Check

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, however, usually do not see a significant performance drop because 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, a trusted library uses J/Direct to expose a single permission to untrusted applets in a safe way. It would be appropriate for this library to turn the call time security check off and perform its own security check for the specific permission.

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

  /** @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();
  }

Note   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:

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, 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.

Security Checks on @dll.struct Classes

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

Security and the com.ms.win32 Classes

For maximum security, the J/Direct methods defined in the com.ms.win32 package 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, copy the required J/Direct declarations into your own classes and disable the per-invocation security check. For more information on disabling the per-invocation security check, see the Security Checks upon Every Invocation section.

© 1999 Microsoft Corporation. All rights reserved. Terms of use.