Go to Visual Studio command prompt and type mscorcfg.msc
<Enter>. Refer to the screen shot below.
Figure 2
When you click on the option "Microsoft .NET Framework
2.0Configuration," you should see the following dialog.
Figure 3
Right click on the Permission Sets and select New.
Figure 4
Now, enter a name for the permission set and click next.
Figure 5
From the available permissions shown in the screen shot
above, select one or more permissions and set the required attributes. In our
case we will choose SQLClient, File IO, User Interface and Security. Refer to
the screen shots below.
Figure 6
Figure 7
Figure 8
Figure 9
Observe that we have set permissions for all the selected
permissions. Now, click on finish. You should be able to see the following
screen.
Figure 10
Next, go to the code groups, right click on All_Code and
select New.
Figure 11
Specify a new to the new code group as shown below.
Figure 12
Select the option "Strong Name" as the condition
type. Remember that at this stage you should be ready to create a strong key
and compiling your project with this key. Once that is done, click the Import
button to import the assembly. You will notice that the public key is copied
into the box. Refer to the screen shot given below.
Figure 13
Then you need to select a permission set from the lost of
the permission sets. We shall select the one we had created earlier. Here is
the screen shot that illustrates the same.
Figure 14
Once that is done, you need to select the first check box in
the membership group. This is because permissions will be a union for more than
one set of policies. By checking the first check box, we are saying to use only
the permissions that we specified.
Figure 15
Now, when you try to execute your project, you will see the
following exception. This exception is thrown because you do not have
permission to access the SqlClient assemblies. Here is the screen shot that
illustrates this.
Figure 16
Note that we have set the read permissions to the Sample.txt
file, but not the write permissions to it. When you click on the next screen,
here is the output that you will see.
Figure 17
Reckoning of Permissions
We have discussed the policy levels and code groups. But,
how would the run time calculate the permissions when the code belongs to
multiple policies or code groups in the same policy? The run time does it in
the following manner.
·
Initially, the entire All_Code group and all its child code
groups are checked for any matching permissions. As said, permissions are identified
by evidences.
·
Then a union of permissions is performed for those identified in
various groups.
The above procedure is repeated for each policy level and
the outcome of permissions at each level are then intersected.
Requesting for Permissions
You might have encountered a time when you wished to check
the permissions for an assembly before actually performing any operations. For
instance, you might have a small windows application that reads configuration
data from the UI and creates an XML file to store that information. But at the
time of saving, the assembly might have not gotten any permission on the C:,
and a security exception was thrown. To handle this, CAS provides three
approaches which can be applied at the assembly level using declarative syntax.
·
RequestMinimum
·
RequestOptional
·
RequestRefuse
RequestMinimum defines the permissions the code requires to
execute. For example, the code below makes an attempt to write into a file. If
the code does not have any permissions for writing then the assembly will not
be loaded.
Listing 2
using System.IO;
using System.Security;
using System.Windows.Forms;
using System.Security.Permissions;
// This is a declarative security call at assembly level.
[FileIOPermissionAttribute(SecurityAction.RequestRefuse, "C:")]
namespace DemoApp
{
public class MyClass
{
//TODO:....
}
}RequestOptional defines permissions that the code can use,
but is not necessarily required to execute. In this case the assembly is loaded,
but if the required permissions are not set then a security exception is thrown
by the run time.
RequestRefuse defines a set of permissions that you might
never want to grant to the code even though the security policy allows the
permissions. Suppose that you need to ensure that you want to read the files
and not even accidentally write into those files, then you could use the
following.
Listing 3
[assembly:FileIOPermission(SecurityAction.RequestRefuse, Write="C:")]
