Permissions Explained

for RuBoard

There are a few different types of permissions in the .NET Framework. The most common form is the code access permission. The next most common type is the identity permission. Finally, a small remaining set of permissions exists, although these permissions don't have a well-defined name or type.

Code Access Permissions

Code access permissions are the permission classes that derive from the abstract class System.Security.CodeAccessPermission . These constitute the standard set of permissions dealt with in assemblies. For example, there are permission classes that represent reading/writing to certain parts of the file system, reading/writing to the event log (on versions of Windows that have an event log), and accessing a database.

Code access permission classes override the following methods from the CodeAccessPermission abstract class:

• Copy ” This method simply creates and returns another permission object that represents the same privilege as the current object.

• Intersect ” This method takes a permission object p and returns a permission object that represents the overlapping privileges of p and the current object. This behavior is as you would expect from set theory.

• Union ” Union is similar to Intersect in that it also behaves as you would expect from set theory. Union takes a permission object p and returns a permission object that represents all the privileges of p and the current object.

• IsSubsetOf ” This method takes a permission object p and returns a Boolean that signifies whether the current object's privileges are wholly contained by the privileges of p . Again, this is as you would expect from set theory.

• ToXml ” When security policy is saved to disk, it must be persisted in some form. Security policy contains permissions, so the permissions must have a way to persist themselves . XML is used for this purpose, so permission classes implement ToXml to achieve this.

• FromXml ” This is how permissions are re-created after they have been persisted to disk. It is worth noting that ToXml and FromXml don't deal directly with XML strings. Instead, there is a small object model based on SecurityElement objects. This eliminates the need for each permission to perform XML parsing directly.

Identity Permissions

Identity permissions are really just a subset of code access permissions, as identity permission classes also derive from CodeAccessPermission . However, the purpose of identity permissions is somewhat different from many other code access permissions. The purpose of an identity permission is to represent the fact that an assembly has a certain piece of evidence during policy resolution. For instance, if an assembly were loaded from the MyComputer zone, it would have a Zone piece of evidence and a ZoneIdentityPermission . Evidence alone isn't always enough; sometimes security decisions need to be made based on the identity of callers , not just on whether security policy allows code to access a certain resource.

Other Permissions

The remaining set of permissions is characterized by the fact that the permission classes do not derive from CodeAccessPermission at all. Instead, they simply implement the System.Security.IPermission and System.Security.ISecurityEncodable interfaces. There is only one permission predefined in the .NET Framework that falls into this category: System.Security.Permissions.PrincipalPermission .

The PrincipalPermission is semantically different from every other predefined permission for one reason: This permission is based on user identity instead of code identity. "Standard" code access permissions and identity permissions are both based on code identity in some way. The PrincipalPermission , on the other hand, uses the role-based security functionality provided in the System.Security.Principal namespace that checks information on user accounts. This permission can be used to check whether code calling an API is being run by a user who is in a certain predefined role or group .

for RuBoard