Upgrading Applications That Use the Visual J++ 6.0 Security Semantics
Applications written in Visual J# follow the security semantics of the .NET Framework and common language runtime. This applies to both new applications written in Visual J# that target the .NET Framework libraries, as well as Visual J++ 6.0 applications that have been upgraded using Visual J#.
Visual J# does not support custom security managers. Therefore, the following methods in the java.lang.System and java.lang.SecurityManager classes are not supported and throw the com.ms.vjsharp.MethodNotSupportedException exception:
The System.getSecurityManager method will always return null.
When upgrading an existing Visual J++ 6.0 application that implements a custom security manager and uses the methods listed above to help implement a security policy, the application must be modified to use the security semantics and classes provided by the .NET Framework.
This usually means using the equivalent APIs in the System.Security namespace and modifying the .NET Framework security policy on the machine to help enforce the required restrictions.
In Visual J#, only fully trusted applications can access the classes in the JDK level 1.1.4, WFC, and com.ms.* packages. This means that only applications that run in the My Computer code group or a code group to which the .NET Framework security policy has granted the FullTrust permission set, can access these classes. Attempting to access these classes from a partially trusted caller will result in a security exception.
However, Visual J# only checks the immediate callers of these classes. Therefore, developers will still be able to build fully trusted but secure libraries and expose them to partially trusted code. Developers of such libraries must make sure that their libraries are fully secure and does not leave the machine vulnerable to exploits.
The JDK level 1.1.4 classes in Visual J# are designed to demand for appropriate .NET Framework permissions before performing sensitive operations. Therefore, fully trusted callers of these classes will be able to fully enforce the semantics of Deny and PermitOnly. Also, when second level callers (potentially malicious) call these trusted callers, some level of protection is afforded by these demands (in that these second level callers will not be able to perform operations for which they do not have permissions).
However, unlike the JDK level 1.1.4 classes, the classes in the WFC and com.ms.* packages do not perform any demands for .NET Framework permissions. Therefore, fully trusted callers of these callers will not be able to implement the semantics of Deny and PermitOnly. (Certain classes like file I/O will do a full stack walk for unrestricted permission set and are an exception).