Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Managing .NET Code Access Security (CAS) Policy : Page 2

Toward the end of the project cycle is not the time to figure out Code Access Security. Learning how .NET handles evidence, permissions, code groups, etc. now will put you that much further ahead for your next project.


advertisement
Evidence
Evidence represents the origin of code. At run time, the .NET Common Language Runtime (CLR) gathers evidence on an assembly that it uses for security as the application executes. Table 1 identifies the type of evidence supplied by .NET by default. Although this article focuses on existing evidence types, you should know that if one of the pre-existing evidence types doesn't meet your needs, you can create your own.

Table 1: Evidence types that ship with .NET.

Evidence Type

Description



Application Directory

Location where the application resides.

Hash

Assembly hash using crypto algorithms such as MD5 or SHA1.

Permission Request

Identifies what permissions an assembly must have.

Publisher

Authenticode signature of the publisher.

Site

Web site the code was launched from.

Strong Name

Assembly strong name.

URL

URL where code was launched from.

Zone

Zone code was launched from.


.NET calculates evidence at run time because it cannot resolve the origin of an assembly until that assembly is executing. For example, if you run an application from a directory of the workstation you're working on, it has Site evidence of localhost. If that same application were launched from a Web site, such as C# Station, its Site evidence would be http://www.csharp-station.com. It is the same assembly, but because its origin differs between invocations, its evidence is different.

Permissions
Evidence is the input to CAS policy and permissions are the output. Permissions specify what a piece of code is allowed to do. Code can only perform actions for the permissions it is given—there are no defaults.

Table 2 shows what permissions come with .NET. While this article only focuses on existing permissions, because CAS is configurable, you can build your own permission classes. To help make it easier to apply policy, .NET lets you combine permissions into permission sets.

Table 2: .NET permissions and protected resources.

Permission Type

Protects

AspNetHostingPermission

ASP.NET hosted environment

DirectoryServicesPermission

Active Directory

DnsPermission

DNS

EnvironmentPermission

Environment variables

EventLogPermission

Windows EventLog

FileDialogPermission

Open and save common dialogs

FileIOPermission

Reading and writing to files

IsolatedStorageFilePermission

Isolated storage

MessageQueuePermission

MSMQ

OdbcPermission

ODBC data sources

OleDbPermission

OLE DB data sources

OraclePermission

Oracle

PerformanceCounterPermission

Performance counters in the Windows Performance Monitor

PrintingPermission

Printer

ReflectionPermission

Reflecting on types

RegistryPermission

Windows registry

SecurityPermission

Working with permissions, security, and unmanaged code

ServiceControllerPermission

Access to Windows services

SocketPermission

Socket IO

SqlClientPermission

SQL Server

UIPermission

User interface drawing

WebPermission

Access Web pages


When you install .NET on your computer, the installation program added the Microsoft .NET Framework 1.1 Configuration tool (Figure 1) to your system to make it easier to work with permissions and configure CAS policy. You will find the Microsoft .NET Framework 1.1 Configuration under Administrative Tools (under the Control Panel). If you have multiple versions of .NET installed on your system, you will have more than one version of this Configuration tool. Be sure to select the one for the version of .NET you need to set policy with.

 
Figure 1: Default permission sets.
Once you've opened the Microsoft .NET Framework 1.1 Configuration tool, select Runtime Security Policy, choose Machine, and then choose Permission Sets. Each Permission Set contains multiple permissions, making it easier to define policy.

You may have noticed two Permission Sets named "FullTrust" and "Everything." FullTrust gives blanket full trust for all permissions, existing and future, that an application will ever need. The Everything permission set covers all permissions that ship with .NET. The Everything permission set does not include the Skip Verification Security permission, which allows an assembly to bypass CLR verification.

Code Groups
Code groups are at the heart of setting CAS policy. Through a series of logical operations on a hierarchical set of code groups, you control what managed code is allowed to do on your system. Code groups are atomic elements in CAS policy that map evidence to permissions. Figure 2 shows the default code groups that ship with .NET.

 
Figure 2: Default code groups.
A single code group contains two members: a membership condition and a permission set. The membership condition accepts a type of evidence. If the provided evidence meets the requirements of the membership condition, the permission set associated with that code group will be used in further evaluation of CAS policy.

For example, in the My_Computer_Zone code group, the Evidence type is Zone. The Membership Condition states that the zone must be MyComputer and the Permission Set is FullTrust. If the assembly was launched from a local directory, the Membership Condition will be met and the FullTrust permission will be added to the set of permissions used to resolve CAS policy. However, if an assembly was launched from a different computer on the LAN or from across the Internet, this code group would not contribute to the set of permissions an assembly is granted.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date