Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Tagged as

Basic Introduction of Code Access Security for Beginners

, 6 Nov 2011 CPOL
Rate this:
Please Sign up or sign in to vote.
A simple theoretical blog to help you learn about what is Code Access Security and its pros and cons.

Introduction

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:

  1. Imperative syntax: Requires an explicitly created permission object that is used to make security checks at runtime.
  2. 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:

  1. Assembly: Consist of a single file or a package of file and includes a manifest that contains import metadata such as permission requirements.
  2. 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.
  3. Policies: Define a set of rules that determine the permissions to be granted to assemblies.
  4. Permissions: Objects that grant code access to resource and authority to perform tasks.
  5. 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.

Stack walking

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.

Reference:

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

RaviRanjankr
Software Developer
India India
Microsoft Student Partner | CS Student | MCTS | CP MVP | Crazy Learner | Dreamer
 
An Indian, who loves his country, believes in freedom, He is an enthusiast Techie and crazy learner. He is passionate about Technologies and social media. He holds bachelor degree of CS in Information Technology and now pursuing Master degree in Computer Application.
 
He always excited and keen Interested in learning and sharing knowledge. He loves to write blog, learn new things, listen music, taking arts and Playing Games..
 
He keep himself on the desk of his imagination, hanging around with some inceptions.
Follow on   Twitter   Google+

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.141223.1 | Last Updated 6 Nov 2011
Article Copyright 2011 by RaviRanjankr
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid