Summary

for RuBoard

So, what have you learned in this chapter? First, you saw how permissions or permission set instances can be created and then acted on by a security operation either declaratively or imperatively:

• Imperative operations look like normal method calls. They are the most flexible form of security request because all parameters of the call can be dynamically computed.

• Declarative operations are specified in the form of attributes attached to the assembly, classes, or methods . They are less flexible than imperative calls because all parameters values are statically computed at compile time. However, there are a couple of operations available declaratively that aren't available to imperative calls ” LinkDemand and InheritanceDemand . LinkDemand , in particular, provides a more performant means of establishing a caller's trust level, at the cost of being harder to use correctly without introducing security holes in your code.

• Declarative security at the method level overrides any at the class level (with the exception of LinkDemand and InheritanceDemand ).

• Declarative security at the assembly level offers distinct functionality from that at the class or method level. The operations supported allow the assembly to modify (but never expand) the set of permissions granted by the security policy system.

• Implicit declarative security is added to P/Invoke calls or methods that call out to unmanaged COM servers. This security can be modified from the default, full stack walking demand, into a cheaper link demand by using the System.Security.SuppressUnmanagedCodeSecurityAttribute custom attribute (on classes/methods for P/Invoke and interfaces for interop).

• Strong named assemblies without the assembly level custom attribute System.Security.AllowPartiallyTrustedCallersAttribute will have an implicit link demand for full trust applied to all their public methods (when called from an external assembly). This reduces the possibility of trusted code written without regard to security being the cause of a security hole.

• Declarative link demands for StrongNameIdentityPermission provide a simple and cheap way of restricting access to your public APIs to other assemblies you own.

We then looked at the process of creating your own custom permissions:

• Permissions must all implement the IPermission interface. This implies implementation of the ISecurityEncodable interface as well.

• Permissions can be CAS (code access security, assigned to specific assemblies) or non-CAS (assigned based on permission implementation). CAS permission must derive from System.Security.CodeAccessPermission . This base class contains all the stackwalking logic plus the logic necessary to associate sets of granted CAS permissions with each assembly.

• Permissions may optionally implement the System.Security.Permissions.IUnrestrictedPermission interface. Doing so will cause the permission to be considered part of the unrestricted (full trust) permission set (which is the norm for most non-identity permissions).

• To be used declaratively, permissions must have an accompanying permission attribute class. Such classes are instantiated at compile time to translate security custom attributes into actual permission instances (which are then serialized and written into metadata).

• Permission and permission attributes should be defined in a different assembly than any code that uses them declaratively.

• Permission attribute code may be restricted to ExectionPermission rights by creating a non-null value for the environment variable _ClrRestrictSecAttributes during compilation.

Finally, we looked at the use of strong names within the build environment:

• The use of strong names requires a public/private key pair. Currently, this key pair is always based on 1024-bit keys using the RSA signing algorithm.

• Key pairs can be created in software using the SN utility and Microsoft's default Cryptographic Service Provider (CSP) or in specially designed hardware using the management utilities provided by the hardware vendor.

• Correspondingly, key pairs can be specified as files or key container names. The latter method allows code to reference key pairs without ever seeing the value of the private key.

• Strong names are added to source code via custom attributes that reference the key pair file or container name . For delay signing, a file containing just the public key is referenced.

• Other utilities, such as TlbImp or ILASM , take the key information as command-line parameters. Reflection emit (dynamic generation of assemblies) allows modification of the System.Reflection.AssemblyName class to specify a full or partial strong name.

• Strong named assemblies cannot be modified in any manner (aside from adding an Authenticode signature) without destroying the strong name signature. Your build environment can cope with this by delaying the signing of assemblies to the last possible stage.

• Delay signed assemblies can be installed and loaded without error on development machines by adding verification skip entries to the registry with the SN utility.

for RuBoard