Before a named permission set can be associated with a code group it needs to be known at that policy level. A new named permission set can be added to a policy using the option –addpset. The permission set needs to be created beforehand as an xml file (see section which is then imported using –addpset (see below). For instance, the command below imports the MyPermissions.xml permission set file as the MyPermissions permission set:
Casol –addpset MyPermissions.xml
The following sections will present more detail about how to actually author and import a named permission set.
In order to add a new permission set using –addpset, an xml file representing the permission set must be authored. As the name indicates, every permission set consists of a set of permissions. Consequently the permission set xml file is simply the xml representation of a number of specific permissions. In general the xml format for standard permissions is the following:
<PermissionSet class=”System.Security.NamedPermissionSet” version=”1”> <Permission class=”System.Security.Permissions.PermissionName, mscorlib,[Ver=XXXX.XX.XXXX.XX], SN=03689116d3a4ae33” version=”…”> [permission xml] </Permission> <Permission class=”System.Security.Permissions.PermissionName, mscorlib,[Ver=XXXX.XX.XXXX.XX], SN=03689116d3a4ae33” version=”…”> [permission xml] </Permission> … <Name>[Name of permission set]</Name> <Description>[description of the permission set]</Description> </PermissionSet>
As can be seen, the permission set file always starts with the <PermissionSet class=”System.Security.NamedPermissionSet” version=”…”> tag, and ends with the </PermissionSet> tag. The <Name> tag simply indicates the name of the permission set (that is the name the permission set will be referred to when it is to be modified or deleted). The content between the <Description> tags should be used to comment on the intended purpose of the permission set (i.e. what permissions are granted from this permission set). Specifying the assembly version (“ver=”) is optional. “SN=” denotes the compact strong name originator of the mscorlib assembly. For the prerelease the version=”..” attribute is ignored. It will be used for forward compatibility and versioning.
The <Permission> tags sandwich the actual XML serialization of specific permissions. The Runtime security system ships with a set of standard permission types that can be used to create specific permissions to be included in named permission sets. For a list of these standard permission sets and their XML format consult ”Schema for the security configuration” of this document.
Below is an example of a small permission set file, representing the FullFileIO permission set.
<PermissionSet class=”System.Security.NamedPermissionSet” version=”1”> <Permission class=”System.Security.Permissions.FileIOPermission, mscorlib, SN=03689116d3a4ae33” version=”1”> <Unrestricted/> </Permission> <Name>FullFileIO</Name> <Description>Gives Full File io</Description> </PermissionSet>
Once a permission set file has been created, it can be added to a policy. The following CASPol command will add the FullFileIO permission set to the user policy level (also see “Importing a named permission set file” below)
CASPol –user –addpset FullFileIO.xml
Custom permissions are permissions that are not shipped as standard ingredients of the runtime security system. It is possible to use custom permissions and include them in permission set files. Custom permissions are surrounded by the permission tags, and a proper permission class+assembly name needs to be specified:
<Permission class=”CustomPermissionClassNamespaceandName, name, [Ver=”XXXX.XX.XXXX.XX], SN=compactStrongNameReprOfAssembly ” version=”…”> [permission xml] </Permission>
The major difference is that class=”” will point to a custom permission class as opposed to a permission class that is shipped with the Runtime. The permission XML in-between the <Permission> tags is completely up to the custom permission developer, since it is entirely processed by the class that implements the custom permission.
There are a number of permission sets that are shipped by default with every policy. In particular, every policy already includes the following permission sets:
These permission sets can be associated with code groups and represent very commonly used permission sets. For some administrative needs it is therefore possible to reuse these permission sets as opposed to having to create a new one.
With the exception of Internet and LocalIntranet, no standard permission set can be changed. Nothing, FullTrust, Everything, Execution and SkipVerification are therefore immutable standard permission sets.
There are two ways to add a new permission set to a policy using –addpset.
Caspol –machine –addpset MyPset.xml
Caspol –addpset MyUnnamedPset.xml FileReadRestrictions