Explore topic-wise InterviewSolutions in .

• First thing CAS was not easy, all those cryptic steps of CREATING code groups, and permission sets etc eats your energy completely.
• If you have to MOVE the assembly to a DIFFERENT computer you need to do the whole rework again.
•  The WORST PART CAS does not work on unmanaged code. I am dead sure it’s always possible you will download exe which is not written in .NET.

Code Group : The evidence provided by an assembly is used as the condition for granting and revoking permissions to it. It is done by putting the code in an appropriate code group. Every code group stipulates a membership condition and has specific conditions attached to it. Any assemblies that meet the condition become a member of the group. Code groups are arranged in a hierarchy and assemblies are nearly always matched to several code groups. The code group at the root of the hierarchy is called All Code and contains all other code groups.

Evidence : In order for the CLR to determine which code group to place assembly information into, the FIRST step is to read supplied evidence. There are two main sources of information, they are internet and intranet. The group internet defines code that is sources from the internet and the group intranet defines code sources from a LAN. The examination of the assembly evidence makes the authentication part of the security process. 

Permissions : Permissions are the actions you ALLOW each code group to perform. The system administrator usually manages the permissions at the enterprise, MACHINE and user levels. The CLR Virtual Execution System (VES) loads and runs programs. It provides the functionality required to execute managed code and uses assembly metadata to connect modules TOGETHER at runtime. When VES loads an assembly, it matches the assembly to one or more code groups. Each code group is assigned to one or more permissions that specify what actions assemblies can do in that code group.

Code Group : The evidence provided by an assembly is used as the condition for granting and revoking permissions to it. It is done by putting the code in an appropriate code group. Every code group stipulates a membership condition and has specific conditions attached to it. Any assemblies that meet the condition become a member of the group. Code groups are arranged in a hierarchy and assemblies are nearly always matched to several code groups. The code group at the root of the hierarchy is called All Code and contains all other code groups.

Evidence : In order for the CLR to determine which code group to place assembly information into, the first step is to read supplied evidence. There are two main sources of information, they are internet and intranet. The group internet defines code that is sources from the internet and the group intranet defines code sources from a LAN. The examination of the assembly evidence makes the authentication part of the security process. 

Permissions : Permissions are the actions you allow each code group to perform. The system administrator usually manages the permissions at the enterprise, machine and user levels. The CLR Virtual Execution System (VES) loads and runs programs. It provides the functionality required to execute managed code and uses assembly metadata to connect modules together at runtime. When VES loads an assembly, it matches the assembly to one or more code groups. Each code group is assigned to one or more permissions that specify what actions assemblies can do in that code group.

ELEMENTS of Code Access Security :

EVERY security system needs some sort of mechanism (such as user name, password and Access Control List (ACL)) to identify the users and DETERMINE what a user can or can't do. However CAS identifies and assigns permissions to application rather than to application users. 

CAS identifies assemblies using evidence, there are a few elements by which an assembly can be identified, such as location, hash code and signature of the assembly. Evidence is the information that the RUNTIME gathers about an assembly to determine which code group the assembly BELONGS to. Code groups in turn grant an assembly a permission set.

Elements of Code Access Security :

Every security system needs some sort of mechanism (such as user name, password and Access Control List (ACL)) to identify the users and determine what a user can or can't do. However CAS identifies and assigns permissions to application rather than to application users. 

CAS identifies assemblies using evidence, there are a few elements by which an assembly can be identified, such as location, hash code and signature of the assembly. Evidence is the information that the runtime gathers about an assembly to determine which code group the assembly belongs to. Code groups in turn grant an assembly a permission set.

• It represents the security context under which code is running.
• The principal object contains information about a user’s identity and ROLE. 
• It represents AUTHENTICATED users.
• You have a Principal Permission object in .NET FRAMEWORK that specifies user and its role. 
• It has Demand() method that checks the current user or principal against the name and role specified in the Principal Permission.
• It encapsulates identity and the role of a user. 
• It can be created with the help of identity and role of a user.

There are two types of code SECURITY:

• Role based security: This authorizes USER. 
• Code access security: This PROTECTS system resources from unauthorized CALLS.

There are two types of code security:

Declarative and imperative are the DIFFERENT syntax schemes used to implement security declarations in .NET Framework. In declarative security, ATTRIBUTE syntax is used. The security constraints are stored in the assembly at compile time. The disadvantage of declarative security is that there are tools which extract security requirements from the metadata in the assembly.

In imperative implementation, the attribute syntax is not used. It is implemented by writing the REGULAR code to provide restrictions

Declarative and imperative are the different syntax schemes used to implement security declarations in .NET Framework. In declarative security, attribute syntax is used. The security constraints are stored in the assembly at compile time. The disadvantage of declarative security is that there are tools which extract security requirements from the metadata in the assembly.

In imperative implementation, the attribute syntax is not used. It is implemented by writing the regular code to provide restrictions

Security checks can be applied imperatively or declaratively. Declarative security is applied by associating ATTRIBUTE declarations that specify a security action with classes or METHODS. IMPERATIVE security is applied by calling the appropriate methods of a Permission object that represents the Principal (for role-based security) or system resource (for code access security).

Security checks can be applied imperatively or declaratively. Declarative security is applied by associating attribute declarations that specify a security action with classes or methods. Imperative security is applied by calling the appropriate methods of a Permission object that represents the Principal (for role-based security) or system resource (for code access security).

• Based on the credentials of the USER, the ACCESS is PROVIDED to the user.
• Role-based authorization is provided by the CLR to an account. It mostly involves the code running with the PRIVILEGES of the CURRENT user.
• Code security is about granting and denying permissions from the permission sets.

• It is a logical GROUPING of code.
• It SPECIFIES the condition for membership.
• Code GROUPS represent collections of code and each code group has an associated set of permissions.
• Administrators CONFIGURE security policy by MANAGING code groups and their associated permission sets.

When you want to execute any code in your environment you would first like to know from where the code came from. Depending from where it came from, you would then would like to give him access rights. For instance a code compiled from your own computer would have GREATER rights than code DOWNLOADED from the internet.

In ORDER to know the same we need to probe the assembly / EXE / dll and get evidences like who is the PUBLISHER of the code , from which site has this code from , from which zone has it come from ( internet , intranet etc) etc.

When you want to execute any code in your environment you would first like to know from where the code came from. Depending from where it came from, you would then would like to give him access rights. For instance a code compiled from your own computer would have greater rights than code downloaded from the internet.

In order to know the same we need to probe the assembly / exe / dll and get evidences like who is the publisher of the code , from which site has this code from , from which zone has it come from ( internet , intranet etc) etc.

Code Access SECURITY is a security MODEL which grants or DENIES permission to your assembly depending on evidences like from where the code has EMERGED, who the publisher is? , STRONG names etc.

Code Access security is a security model which grants or denies permission to your assembly depending on evidences like from where the code has emerged, who the publisher is? , strong names etc.

Once you have gathered the evidences about the CODE you would LIKE to assign permission to the code. There are various PERMISSIONS which you can assign to the code like Can the code create a file, can we write to REGISTRY, can the code execute reflection, can the code OPEN file dialog box etc. 

These permissions are collect permission sets and those permission sets are allocated to the code.

Once you have gathered the evidences about the code you would like to assign permission to the code. There are various permissions which you can assign to the code like Can the code create a file, can we write to registry, can the code execute reflection, can the code open file dialog box etc. 

These permissions are collect permission sets and those permission sets are allocated to the code.

It’s the core exe which is responsible to assign permission to the assembly. The .NET CONFIGURATION tool is just a cover which sits on the TOP of caspol.exe to ease our work. CASPOL.exe commands are cryptic so the .NET configuration tool is more user friendly. In case you are INTERESTED in using caspol.exe you can go to visual STUDIO command prompt and type caspol.exe with necessary parameters.

It’s the core exe which is responsible to assign permission to the assembly. The .NET configuration tool is just a cover which sits on the top of caspol.exe to ease our work. CASPOL.exe commands are cryptic so the .NET configuration tool is more user friendly. In case you are interested in using caspol.exe you can go to visual studio command prompt and type caspol.exe with necessary parameters.

It performs following function:

1. Defines permissions and permission sets that represent the right to access VARIOUS system resources.
2. Enables administrators to configure security policy by associating sets of permissions with groups of CODE (code groups).
3. Enables code to request the permissions it requires in order to run, as well as the permissions that would be useful to have, and specifies which permissions the code must never have.
4. Grants permissions to each assembly that is LOADED, based on the permissions requested by the code and on the operations permitted by security policy.
5. Enables code to demand that its callers have specific permissions.
6. Enables code to demand that its callers possess a digital signature, THUS allowing only callers from a particular organization or site to call the protected code.
7. ENFORCES restrictions on code at run time by comparing the granted permissions of every caller on the call stack to the permissions that callers must have.

It performs following function:

YES. Use caspol -ap, specifying an XML file containing the permissions in the permission set. To save you some time, here is a sample file corresponding to the 'Everything' permission set - just edit to suit your needs. When you have edited the sample, ADD it to the range of available permission sets LIKE this:

caspol -ap samplepermset.xml
Then, to apply the permission set to a code GROUP, do something like this:
caspol -cg 1.3 SamplePermSet
(By default, 1.3 is the 'Internet' code group)

Yes. Use caspol -ap, specifying an XML file containing the permissions in the permission set. To save you some time, here is a sample file corresponding to the 'Everything' permission set - just edit to suit your needs. When you have edited the sample, add it to the range of available permission sets like this:

caspol -ap samplepermset.xml
Then, to apply the permission set to a code group, do something like this:
caspol -cg 1.3 SamplePermSet
(By default, 1.3 is the 'Internet' code group)

USE caspol. If you are the machine administrator, you can operate at the 'machine' level - which means not only that the changes you make become the default for the machine, but also that users cannot change the permissions to be more permissive. If you are a NORMAL (non-admin) user you can still modify the permissions, but only to make them more restrictive. For example, to allow intranet CODE to do what it likes you MIGHT do this:

caspol -CG 1.2 FullTrust

Note that because this is more permissive than the default policy (on a standard system), you should only do this at the machine level - doing it at the user level will have no effect.

Use caspol. If you are the machine administrator, you can operate at the 'machine' level - which means not only that the changes you make become the default for the machine, but also that users cannot change the permissions to be more permissive. If you are a normal (non-admin) user you can still modify the permissions, but only to make them more restrictive. For example, to allow intranet code to do what it likes you might do this:

caspol -cg 1.2 FullTrust

Note that because this is more permissive than the default policy (on a standard system), you should only do this at the machine level - doing it at the user level will have no effect.

Use caspol. For example, suppose you trust code from www.mydomain.com and you want it have full ACCESS to your SYSTEM, but you want to KEEP the default restrictions for all other internet sites. To achieve this, you would add a new code group as a sub-group of the 'Zone - Internet' group, like this:

caspol -AG 1.3 -site www.mydomain.com FullTrust 
Now if you run caspol -lg you will SEE that the new group has been added as group 1.3.1:
...

1.3. Zone - Internet: Internet
1.3.1. Site - www.mydomain.com: FullTrust

...
Note that the numeric label (1.3.1) is just a caspol invention to make the code groups easy to manipulate from the command-line. The underlying runtime never sees it.

Use caspol. For example, suppose you trust code from www.mydomain.com and you want it have full access to your system, but you want to keep the default restrictions for all other internet sites. To achieve this, you would add a new code group as a sub-group of the 'Zone - Internet' group, like this:

caspol -ag 1.3 -site www.mydomain.com FullTrust 
Now if you run caspol -lg you will see that the new group has been added as group 1.3.1:
...

1.3. Zone - Internet: Internet
1.3.1. Site - www.mydomain.com: FullTrust

...
Note that the numeric label (1.3.1) is just a caspol invention to make the code groups easy to manipulate from the command-line. The underlying runtime never sees it.

MICROSOFT defines some default ones, but you can modify these and even CREATE your own. To see the code groups defined on your SYSTEM, run 'caspol -lg' from the command-line. On my system it looks like this:
Level = Machine
Code Groups:

1. All code: Nothing
1.1. Zone - MyComputer: FullTrust
1.1.1. Honor SkipVerification requests: SkipVerification
1.2. Zone - Intranet: LocalIntranet
1.3. Zone - INTERNET: Internet
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.6. StrongName -

0024000004800000940000000602000000240000525341310004000003
000000CFCB3291AA715FE99D40D49040336F9056D7886FED46775BC7BB5430BA4444FEF8348EBD06
F962F39776AE4DC3B7B04A7FE6F49F25F740423EBF2C0B89698D8D08AC48D69CED0FC8F83B465E08
07AC11EC1DCC7D054E807A43336DDE408A5393A48556123272CEEEE72F1660B71927D38561AABF5C
AC1DF1734633C602F8F2D5: Everything

Note the hierarchy of code groups - the top of the hierarchy is the most general ('All code'), which is then sub-divided into several groups, each of which in turn can be sub-divided. Also note that (somewhat counter-intuitively) a sub-group can be associated with a more permissive permission set than its parent.

Microsoft defines some default ones, but you can modify these and even create your own. To see the code groups defined on your system, run 'caspol -lg' from the command-line. On my system it looks like this:
Level = Machine
Code Groups:

1. All code: Nothing
1.1. Zone - MyComputer: FullTrust
1.1.1. Honor SkipVerification requests: SkipVerification
1.2. Zone - Intranet: LocalIntranet
1.3. Zone - Internet: Internet
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.6. StrongName -

0024000004800000940000000602000000240000525341310004000003
000000CFCB3291AA715FE99D40D49040336F9056D7886FED46775BC7BB5430BA4444FEF8348EBD06
F962F39776AE4DC3B7B04A7FE6F49F25F740423EBF2C0B89698D8D08AC48D69CED0FC8F83B465E08
07AC11EC1DCC7D054E807A43336DDE408A5393A48556123272CEEEE72F1660B71927D38561AABF5C
AC1DF1734633C602F8F2D5: Everything

Note the hierarchy of code groups - the top of the hierarchy is the most general ('All code'), which is then sub-divided into several groups, each of which in turn can be sub-divided. Also note that (somewhat counter-intuitively) a sub-group can be associated with a more permissive permission set than its parent.

The CAS security policy revolves around two key concepts - code groups and permissions. Each .NET assembly is a member of a PARTICULAR code group, and each code group is granted the permissions specified in a named PERMISSION set.

For example, using the default security policy, a control DOWNLOADED from a web SITE belongs to the 'Zone - Internet' code group, which adheres to the permissions defined by the 'Internet' named permission set. (Naturally the 'Internet' named permission set represents a very restrictive range of permissions.)

The CAS security policy revolves around two key concepts - code groups and permissions. Each .NET assembly is a member of a particular code group, and each code group is granted the permissions specified in a named permission set.

For example, using the default security policy, a control downloaded from a web site belongs to the 'Zone - Internet' code group, which adheres to the permissions defined by the 'Internet' named permission set. (Naturally the 'Internet' named permission set represents a very restrictive range of permissions.)