Saturday, July 12, 2008

CODE ACCESS SECURITY

Today’s Security Paradigm:
Role Based Security

Primary Security Identity:
User identity or role
Authentication:
User supplied login credentials
Authorization & Enforcement:
Each resource (file system, COM+, Registry, …) enforces its own permission scheme, often with proprietary permission stores and management tools.

Limitations of the Existing Paradigm

1. A component accessing n resources requires n security definitions:

2. m components, n resources could require
n*m security definitions:

3. In real-life, we have x servers * y applications * m components * n resources.

x * y * m * n =

… = Hard to configure, even harder to maintain over time
… = Determining the minimal permission set is non-
trivial
… = Not suitable for many scenarios, such as
embedded ActiveX controls, mobile code, etc.

Code Access Security: Concepts

Permissions
Evidence
Code Groups
Policies

Permissions

Represents authorization to perform specific actions against a specific resource
Example: Read access to C:\TEMP
.NET class libraries support permissions on all resources
DataAccess, DNS, DirectoryServices, FileIO, EventLog, Environment, FileDialog, UI, Printing, Registry, Reflection, Socket, Web, IsolatedStorage, MessageQueue, Security
.NET allows fine-grained control over resources

Evidence

Descriptive data about an assembly
URL of origin, site, zone
Strong Name signature, Authenticode signature, hash
Host-defined
Trustworthy
Basis for assigning security rules
Computed at load time of assembly by CLR
Hosts can add their own evidence
See System.Security.Policy.Evidence

Code Groups

Groups of assemblies with something in common
Permissions are assigned to code groups
Built-in and custom code groups
Evidence is used to determine membership of an assembly to one or more code groups

Policies

Set of rules that assign trust to an assembly
Specified by Administrator using the
.NET Configuration Tool
Multiple, Ordered Policy Levels
Enterprise, Machine and User
Input: Data describing an assembly (Evidence)
location, digital signature, hash, “host-defined”
Output: Set of rights to access protected resources (Permissions)

What is Code Access Security (CAS)? How does CAS work? Who defines the CAS code groups?

Code Access Security (CAS) is part of the .NET security model. CAS determines whether or not a piece of code is allowed to run and also what resources to use. For example, CAS will prevent malicious code from entering your system and causing havoc.

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. An example: Using the default security policy, a control downloaded from a web site belongs to the 'Zone - Internet' code group which complies to the permissions defined by the 'Internet' named permission set.

Microsoft defines some default policies but you can modify these and even create your own. To view the code groups defined on your system; Run 'caspol' from the command-line and checkout the different options on display.

How Code Access Security works?





Coding for CAS

How CAS Works

There are two ways to code CAS:
Imperative (method implementation)
Declarative (method metadata)

Imperative Checks

Actions occur at runtime as part of a method
Can be used for members only (not classes)

using System.Security.Permissions;
public void SomethingWhichWritesToDriveC() {
// describe your request
IPermission request = new FileIOPermission(
FileIOPermissionAccess.Write,"c:\\windows");
// make the request
request.Demand(); // throws SecurityException on failure
// if we're still here, the demand succeeded!
}
}

Declarative Checks

Implemented with custom attributes
Cannot contain runtime variables
The compiler converts the annotation to a check

Using … ;

[FileIOPermission(SecurityAction.Demand, Write=“c:\\windows")]
public void SomethingWhichWritesToDriveC() {
// this method writes to c:\temp
}

Imperative vs. Declarative

Use imperative security for:
Places where security involves run-time logic or application flow control.
Use declarative security for:
Method or Assembly level CAS
Enabling reviewers and automated tools to see how security is implemented and which permissions are required.

On making “Demands”

Checks all callers for the required permission

Checks Enforced through Stack Walk

Failed Demands raise a SecurityException

No more luring attacks

Stack Walk Modifiers

Modifiers allow fine-grained control of the stack walk
Assert, Deny, PermitOnly
Most common modifier is Assert
“I vouch for my callers; checks for this permission can stop with me”
Use with Caution!!
These are beyond the scope of the current talk

Summary

CAS is based on code identity
Augments Windows Security Model
Administrators Set Security Policy
Evidence determines the granted Permissions
.Net Configuration Tool / CASPOL.EXE
Code Authors Demand Permissions
CLR uses the call stack to enforce policy

… This is only the tip of the iceberg …

Remember:

Using CAS can reduce the likelihood that your code can be misused by malicious or error-filled code

It can reduce your liability because you can specify the set of operations your code should be allowed to perform as well as the operations your code should never be allowed to perform

Code access security can also help minimize the damage that can result from security vulnerabilities in your
Code

How does CAS work?

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.)

Who defines the CAS code groups?

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:
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.

How do I define my own code group?

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.

How do I change the permission set for a 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.

I can't be bothered with all this CAS stuff. Can I turn it off?

Yes, as long as you are an administrator. Just run: caspol -s off

No comments: