Security Considerations for Devices

[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]

There are several important and unique security considerations for the .NET Compact Framework:

  • The .NET Compact Framework does not currently support code access security. The following code should be removed when converting applications from the full (desktop) .NET Framework:

    • Security permission objects.

    • Security demands.

    • Any evidence, including strong names.

    • Code groups.

  • The .NET Compact Framework types do not support the AllowPartiallyTrustedCallersAttribute attribute. In the full .NET Framework class library, many member reference topics contain warnings that the member requires full trust for the immediate caller. Because the .NET Compact Framework does not support the AllowPartiallyTrustedCallersAttribute, unrestricted access is granted by default to all libraries. Future versions of the .NET Compact Framework will include demands for specific permissions to restrict access to high-trust features. Security policy will then grant specific permissions to code where appropriate.

  • Devices can be engineered to accept updates to system software and be subject to security controls beyond the scope of the .NET Compact Framework.

  • If the device supports native code that is not trusted, full security cannot be achieved. Security enforcement is valid only for verifiably type-safe code. The boundary between managed and unmanaged code is a serious security threat to managed code.

  • In the .NET Compact Framework version 1.0, the runtime does not restrict platform invoke access to native code.

Multiple device manufacturers present cross-platform implications:

  • The original equipment manufacturer (OEM) determines the platform security level of the device and its security policy and can also provide a security administrator with custom permissions for granting access.

  • Strong-name evidence can be incompatible across platforms and can impact applications. However, a secure binding policy on each platform can alleviate the need for most applications to demand strong-name evidence of standard assemblies.

  • Independent software vendors (ISVs) can enforce a set of security demands from within their own code without requiring changes to security policy on the device.

Security policies vary according to the type of the device and how it is used. The .NET Compact Framework accommodates cross-device portability while maintaining strong security practices.