Export (0) Print
Expand All

Platform Invoke Security Considerations

The Assert, Deny, and PermitOnly members of the SecurityAction enumeration are referred to as stack walk modifiers. These members are ignored if they are used as declarative attributes on platform invoke declarations and COM Interface Definition Language (IDL) statements.

The platform invoke samples in this section illustrate the use of the RegistryPermission attribute with the stack walk modifiers.

In the following code example, the SecurityAction Assert, Deny, and PermitOnly modifiers are ignored.

[DllImport("MyClass.dll", EntryPoint = "CallRegistryPermission")]
[RegistryPermission(SecurityAction.Assert, Unrestricted = true)]
    private static extern bool CallRegistryPermissionAssert();

[DllImport("MyClass.dll", EntryPoint = "CallRegistryPermission")]
[RegistryPermission(SecurityAction.Deny, Unrestricted = true)]
    private static extern bool CallRegistryPermissionDeny();

[DllImport("MyClass.dll", EntryPoint = "CallRegistryPermission")]
[RegistryPermission(SecurityAction.PermitOnly, Unrestricted = true)]
    private static extern bool CallRegistryPermissionDeny();

However, the Demand modifier in the following example is accepted.

[DllImport("MyClass.dll", EntryPoint = "CallRegistryPermission")]
[RegistryPermission(SecurityAction.Demand, Unrestricted = true)]
    private static extern bool CallRegistryPermissionDeny();

SecurityAction modifiers do work correctly if they are placed on a class that contains (wraps) the platform invoke call.

[RegistryPermission(SecurityAction.Demand, Unrestricted = true)]
class PInvokeWrapper
{
[DllImport("MyClass.dll", EntryPoint = "CallRegistryPermission")]
    private static extern bool CallRegistryPermissionDeny();
}

SecurityAction modifiers also work correctly in a nested scenario where they are placed on the caller of the platform invoke call:

class PInvokeScenario
{
    [DllImport("MyClass.dll", EntryPoint = "CallRegistryPermission")]
    private static extern bool CallRegistryPermissionInternal();

    [RegistryPermission(SecurityAction.Assert, Unrestricted = true)]
    public static bool CallRegistryPermission()
    {
     return CallRegistryPermissionInternal();
    }
}

The COM interop samples in this section illustrate the use of the RegistryPermission attribute with the stack walk modifiers.

The following COM interop interface declarations ignore the Assert, Deny, and PermitOnly modifiers, similarly to the platform invoke examples in the previous section.

[ComImport, Guid("12345678-43E6-43c9-9A13-47F40B338DE0")]
interface IAssertStubsItf
{
[RegistryPermission(SecurityAction.Assert, Unrestricted = true)]
    bool CallRegistryPermission();
[FileIOPermission(SecurityAction.Assert, Unrestricted = true)]
    bool CallFileIoPermission();
}

[ComImport, Guid("12345678-43E6-43c9-9A13-47F40B338DE0")]
interface IDenyStubsItf
{
[RegistryPermission(SecurityAction.Deny, Unrestricted = true)]
    bool CallRegistryPermission();
[FileIOPermission(SecurityAction.Deny, Unrestricted = true)]
    bool CallFileIoPermission();
}

[ComImport, Guid("12345678-43E6-43c9-9A13-47F40B338DE0")]
interface IAssertStubsItf
{
[RegistryPermission(SecurityAction.PermitOnly, Unrestricted = true)]
    bool CallRegistryPermission();
[FileIOPermission(SecurityAction.PermitOnly, Unrestricted = true)]
    bool CallFileIoPermission();
}

Additionally, the Demand modifier is not accepted in COM interop interface declaration scenarios, as shown in the following example.

[ComImport, Guid("12345678-43E6-43c9-9A13-47F40B338DE0")]
interface IDemandStubsItf
{
[RegistryPermission(SecurityAction.Demand, Unrestricted = true)]
    bool CallRegistryPermission();
[FileIOPermission(SecurityAction.Demand, Unrestricted = true)]
    bool CallFileIoPermission();
}
Show:
© 2014 Microsoft