Unmanaged Code


Code that calls unmanaged Win32 APIs or COM components requires the unmanaged code permission. This should only be granted to highly trusted code. It is defined by the SecurityPermission type with its Flags property set to SecurityPermissionFlag.UnmanagedCode .

The following guidelines for calling unmanaged code build upon those introduced in Chapter 7, "Building Secure Assemblies."

  • Use naming conventions to indicate risk .

  • Request the unmanaged code permission .

  • Sandbox unmanaged API calls .

  • Use SupressUnmanagedCodeSecurityAttribute with caution .

Use Naming Conventions to Indicate Risk

Categorize your unmanaged code and prefix the types used to encapsulate the unmanaged APIs by using the following naming convention.

  • Safe . This identifies code that poses no possible security threat. It is harmless for any code, malicious or otherwise , to call. An example is code that returns the current processor tick count. Safe classes can be annotated with the SuppressUnmanagedCode attribute which turns off the code access security permission demand for full trust.

     [SuppressUnmanagedCode] class SafeNativeMethods {        [DllImport("user32")]        internal static extern void MessageBox(string text); } 
  • Native . This is potentially dangerous unmanaged code, but code that is protected with a full stack walking demand for the unmanaged code permission. These are implicitly made by the interop layer unless they have been suppressed with the SupressUnmanagedCode attribute.

     class NativeMethods {        [DllImport("user32")]        internal static extern void FormatDrive(string driveLetter); } 
  • Unsafe . This is potentially dangerous unmanaged code that has the security demand for the unmanaged code permission declaratively suppressed. These methods are potentially dangerous. Any caller of these methods must do a full security review to ensure that the usage is safe and protected because no stack walk is performed.

     [SuppressUnmanagedCodeSecurity] class UnsafeNativeMethods {        [DllImport("user32")]        internal static extern void CreateFile(string fileName); } 

Request the Unmanaged Code Permission

Strong-named

 [assembly: SecurityPermission(SecurityAction.RequestMinimum,                                UnmanagedCode=true)] 

Sandbox Unmanaged API Calls

Isolate calls to unmanaged code in specific assemblies and keep the number of assemblies that call unmanaged code to a minimum. Then, use the sandboxing pattern to ensure that the unmanaged code permission is only granted to selected assemblies.

 Task   To sandbox your managed code that calls unmanaged code

  1. Place your code that calls unmanaged code in a separate (wrapper) assembly.

  2. Add a strong name to the assembly.

    This allows custom code access security policy to be easily applied to the assembly. For more information, see the "Strong Names" section in Chapter 7, "Building Secure Assemblies."

  3. Request the unmanaged code permission (as described in the preceding section.)

  4. Authorize calling code with a full permission demand.

    You typically need to use a custom permission that represents the unmanaged resource being exposed by your assembly. For example:

     (new EncryptionPermission(EncryptionPermissionFlag.Encrypt,                            storePermissionFlag.Machine)).Demand(); 
  5. Assert the unmanaged code permission in your wrapper class:

     (new SecurityPermission(SecurityPermissionFlag.UnmanagedCode)).Assert(); 

For a full example implementation that shows you how to call the unmanaged Win32 DPAPI functionality, see "How To: Create a Custom Encryption Permission," in the "How To" section of this guide.

Use SuppressUnmanagedCodeSecurity with Caution

If your assembly makes many calls to unmanaged code, the performance overhead associated with multiple unmanaged code permission demands can become an issue.

In this case, you can use the SupressUnmanagedCodeSecurity attribute on the P/Invoke method declaration. This causes the full demand for the unmanaged permission to be replaced with a link demand which only occurs once at JIT compilation time.

In common with the use of link demands, your code is now vulnerable to luring attacks. To mitigate the risk, you should only suppress the unmanaged code permission demand if your assembly takes adequate precautions to ensure it cannot be coerced by malicious code to perform unwanted operations. An example of a suitable countermeasure is if your assembly demands a custom permission that more closely reflects the operation being performed by the unmanaged code

Using SuppressUnmanagedCodeSecurity with P/Invoke

The following code shows how to apply the SuppressUnmanagedCodeSecurity attribute to a Platform Invocation Services (P/Invoke) method declaration.

 public NativeMethods {   // The use of SuppressUnmanagedCodeSecurity here applies only to FormatMessage   [DllImport("kernel32.dll"), SuppressUnmanagedCodeSecurity]   private unsafe static extern int FormatMessage(                                       int dwFlags,                                        ref IntPtr lpSource,                                        int dwMessageId,                                       int dwLanguageId,                                        ref String lpBuffer, int nSize,                                        IntPtr *Arguments); } 

Using SuppressUnmanagedCodeSecurity with COM Interop

For COM interop calls, the attribute must be used at the interface level, as shown in the following example.

 [SuppressUnmanagedCodeSecurity] public interface IComInterface { } 



Improving Web Application Security. Threats and Countermeasures
Improving Web Application Security: Threats and Countermeasures
ISBN: 0735618429
EAN: 2147483647
Year: 2003
Pages: 613

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net