This is a simple theoretical blog to help you learn about what is Code Access Security and its pros and cons.
Code access security is the central security scheme in the .NET Framework, used automatically by the runtime. It helps you restrict access
to import sensitive operation and resources. To lock systems and protect them against malicious code, you need to provide the least privilege,
which gives user and code only the freedom absolutely necessary to perform their task. Code access security helps you achieve this principle of least privilege.
Benefit of Code access security
In the past, role based security systems relied on permissions granted to the user. The .NET Framework’s code access security mechanism helps grant access permission to code.
Many objects such as file, directories, and registry key in the Windows Operating System are controlled by access lists that specify which users should have access and the kind
of access they are allowed. User indentity is therefore important in evaluating access permissions for the resource's code. However, sometimes a trusted user may need
to run code for uncertain origin such as an application available from an external website. In such cases role based security does little to protect your computer
against malicious code. Evidence-based security, on the other hand, can help identify suspected programs and can limit their ability to do damage.
Important Features of Code Access Security
An important feature of code access security is that it can function reliably only when code is verifiably type safe. If code is not type safe, it can breach security
checks by making calls to the restricted areas of memory.
For example: It is not legal to write type safe code that directly accesses the private member variables of an object. However, it is safe.
The CLR verifies that code is type safe and by default allows non-typesafe code to run only if it originates from the local omputer. It is also possible
to set a security policy that restricts the execution of any code that is not type safe.
Another limitation of code access security is that it does not protect the user who downloads an application from the Internet and runs it locally.
The default poilicy of local applications is to grant full trust so that such an application is free to access any of the user resources.
Specifying security permission in code
There are two ways of specifying security permission in your code:
- Imperative syntax: Requires an explicitly created permission object that is used to make security checks at runtime.
- Declarative syntax: Uses code attributes to specify permission that is required to execute an assembly, a particular class, or particular
method in a class. Rules in a security policy.
Security policies can be configured by using the Microsoft .NET Framework 2.0 Configuration utility. Policies consist of rules that can be specified at three
different levels: Enterprise, Machine and User. At the Enterprise level, you can set blanket rule across an entire company, department,
or group of computers. Machine and user level allow you to specify security rule that restrict permissions for individual computer and users.
Primary entities in the code access security architecture
The following are the entities envolved in the code access security architecture:
- Assembly: Consist of a single file or a package of file and includes a manifest that contains import metadata such as permission requirements.
- Evidence: Refers to information about the origin of the code, such as a URL or a Zone. Such information is either in the assembly or provided
by the host in which the assembly is executed.
- Policies: Define a set of rules that determine the permissions to be granted to assemblies.
- Permissions: Objects that grant code access to resource and authority to perform tasks.
- Principals: Object that represent both the identity and roles of a user. Evry thread or process is associated with a principal.
By using role-based security. Permission can be granted and denied according to the identity or the roles of the principal.
A powerful feature of the code access security architecture is that it can evaluate permission demand by walking up the call stack. For example, consider what happen
when a method in one assembly call another assembly and in this second assembly, a request is made for a particular permission. It is possible that the evidence presented
by the second assembly is enough to obtain the permission. however, it is also possible that the evidence in the first assembly does not grant permission on request.
By default the runtime walks up the call stack to guard against such possibilities.