Code Access Security (.NET 1.1) Security Checklist

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan

Code Access Security Considerations

If an entry is preceded by a star (*), it indicates that the checks are performed by the FXCop analysis tool. For more information about FXCop security checks, see http://www.gotdotnet.com/team/libraries/FxCopRules/SecurityRules.aspx.

• Assemblies marked with AllowPartiallyTrustedCallersAttribute (APTCA) do not expose objects from non-APTCA assemblies.
• Code that only supports full-trust callers is strong named or explicitly demands the full-trust permission set.
• All uses of Assert are thoroughly reviewed.
• All calls to Assert are matched with a corresponding call to RevertAssert.
• (*)The Assert window is as small as possible.
• (*)Asserts are proceeded with a full permission demand.
• (*)Use of Deny or PermitOnly is thoroughly reviewed.
• All uses of LinkDemand are thoroughly reviewed. (Why is a LinkDemand and not a full Demand used?)
• LinkDemands within Interface declarations are matched by LinkDemands on the method implementation.
• (*) Unsecured members do not call members protected by a LinkDemand.
• Permissions are not demanded for resources accessed through the .NET Framework classes.
• Access to custom resources (through unmanaged code) is protected with custom code access permissions.
• Access to cached data is protected with appropriate permission demands.
• If LinkDemands are used on structures, the structures contain explicitly defined constructors.
• (*) Methods that override other methods that are protected with LinkDemands also issue the same LinkDemand.
• (*) LinkDemands on types are not used to protect access to fields inside those types.
• (*) Partially trusted methods call only other partially trusted methods.
• (*) Partially trusted types extend only other partially trusted types.
• (*) Members that call late bound members have declarative security checks.
• (*) Method-level declarative security does not mistakenly override class-level security checks.
• Use of the following "potentially dangerous" permissions is thoroughly reviewed:
  • SecurityPermission
  • Unmanaged Code
  • SkipVerification
  • ControlEvidence
  • ControlPolicy
  • SerializationFormatter
  • ControlPrincipal
  • ControlThread
  • ReflectionPermission
  • MemberAccess
• Code identity permission demands are used to authorize calling code in scenarios where you know in advance the range of possible callers (for example, you want to limit calling code to a specific application).
• Permission demands of the .NET Framework are not duplicated.
• Inheritance is restricted with SecurityAction.InheritanceDemand in scenarios where you want to limit which code can derive from your code.