Code-Access Permissions and Security in the .NET Framework with Visual Basic

Article
11/16/2012

In the .NET Framework, code-access security limits the access that code has to protected resources and operations. Every application that targets the common language runtime must interact with the runtime's security system. When an application executes, it is automatically evaluated and given a set of permissions by the runtime. Depending on the permissions that the application receives, it either runs properly or generates a security exception.

The local security settings on a particular computer ultimately control which permissions your code receives. Because these settings can change from computer to computer, you can never be sure that your code will receive sufficient permissions to run. For more information, see Code Access Security Basics.

Code-Access Permissions

Code-access-permission objects are used to protect resources and operations from use by unauthorized users. They are a fundamental part of the common language runtime's mechanism for enforcing security restrictions on managed code.

Code-access permissions allow a user to access a protected resource, such as a file, or to perform a protected action, such as accessing managed code. All code-access permissions can be requested by code; whether or not permissions are granted is determined by the runtime. Each code-access permission derives from the CodeAccessPermission class, and therefore permissions have common methods: Assert, Demand, Deny, PermitOnly, IsSubSetOf, Intersect, and Union.

Permissions Provided by the .NET Framework

This table shows the code-access permissions provided by the .NET Framework.

Permission class	Allows
AspNetHostingPermission	Access to resources in ASP.NET-hosted environments.
DirectoryServicesPermission	Access to the System.DirectoryServices classes.
DnsPermission	Access to Domain Name System (DNS) servers on a network.
EnvironmentPermission	Reading from or writing to environment variables.
EventLogPermission	Reading from or writing to event log services.
FileDialogPermission	Reading from or writing to files by means of an Open dialog box.
FileIOPermission	Reading from or writing to files or directories.
IsolatedStorageFilePermission	Reading from or writing to files or directories in isolated storage.
MessageQueuePermission	Access to message queues through the managed Message Queuing (also known as MSMQ) interfaces.
OdbcPermission	Accessing ODBC (Open Database Connectivity) data sources.
OleDbPermission	Accessing databases using OLE DB.
OraclePermission	Accessing Oracle databases.
PerformanceCounterPermission	Accessing performance counters.
PrintingPermission	Accessing printers.
ReflectionPermission	Determining information about a type at run time.
RegistryPermission	Reading from, writing to, creating, or deleting registry keys and values.
SecurityPermission	Executing, asserting permissions, calling into unmanaged code, skipping verification, and other security-related rights.
ServiceControllerPermission	Accessing running or stopped services.
SocketPermission	Making or accepting connections on a transport address.
SqlClientPermission	Accessing SQL databases.
UIPermission	Accessing user interface functionality.
WebPermission	Making or accepting connections on a Web address.

Creating Your Own Permissions

The .NET Framework supplies a set of code-access-permission classes designed to help protect a specific set of resources and operations, focusing on those resources exposed by the .NET Framework. For most environments, the built-in code-access permissions are adequate. However, in some situations, it might make sense to define your own code-access-permission class. For more information, see Creating Your Own Code Access Permissions.

Identity Permissions

Identity permissions represent characteristics that identify an assembly. The common language runtime grants identity permissions to an assembly when it is loaded, based on the information it obtains about the assembly. For more information, see Identity Permissions.

Role-based Permissions

Business applications often provide access to data or resources based on credentials supplied by the user. Typically, such applications check the role of a user and provide access to resources based on that role. The common language runtime provides support for role-based authorization based on a Windows account or a custom identity. For more information, see Role-Based Security.

Security Tasks

The following table lists tasks associated with permissions and security.

To	See
Request permission to access unmanaged code	How to: Request Permission to Access Unmanaged Code
Request optional permissions	How to: Request Optional Permissions by Using the RequestOptional Flag
Request permission for a named permission set	How to: Request Permission for a Named Permission Set
Request XML-encoded permissions	Requesting XML-Encoded Permissions
Refuse permissions	How to: Refuse Permissions by Using the RequestRefuse Flag
Perform an imperative security check	How to: Perform Imperative Security Checks
Perform a declarative security check	Performing Declarative Security Checks
Override a security check	Overriding Security Checks
Share a library with partially trusted code	Sharing a Library with Partially Trusted Code
Require full trust for types within an AllowPartiallyTrustedCallersAttribute assembly	Requiring Full Trust for Types Within an AllowPartiallyTrustedCallersAttribute Assembly
Create WindowsIdentity and WindowsPrincipal objects	How to: Create a WindowsPrincipal Object
Create GenericPrincipal and GenericIdentity objects	How to: Create GenericPrincipal and GenericIdentity Objects

The .NET Framework Security Policy Model

Five elements make up the .NET Framework security policy model. They are:

Security policy levels: enterprise, machine, user, and application domain.
Code groups, which exist as a hierarchy within the enterprise, machine, and user policy levels.
Named permission sets associated with each code group.
Evidence that provides information about the identity of code.
Application domain hosts that provide evidence about code to the common language runtime.

Security Policy Levels

Four security policy levels are provided by the .NET Framework to compute the permission grant of an assembly or application domain. Each level contains its own hierarchy of code groups and permission sets. The runtime computes the allowed permission set as the sum of permissions allowed by all participating levels in a policy

The levels are:

Enterprise policy. Applies to all managed code in an enterprise setting where an enterprise configuration file is distributed.
Machine policy. Applies to all managed code on the computer.
User policy. Applies to code in all the processes associated with the current operating-system user when the common language runtime starts.
Application domain policy. Applies to managed code in the host's application domain.

For more information, see Security Policy Levels.

Code Groups

A code group is a logical grouping of code that has a specified condition for membership. Any code that meets the membership condition is included in the group. Code groups have associated permission sets that are evaluated during a policy grant. For more information, see Code Groups.

Named Permission Sets

A named permission set is a set of permissions that administrators can associate with a code group. A named permission set consists of at least one permission, as well as a name and description for the set. More than one code group can be associated with a specific permission set.

This table shows the named permission sets provided by the common language runtime.

Name	Description
Nothing	No permissions (code cannot run).
Execution	Permission to run (execute), but no permissions to use protected resources.
Internet	Default policy permission set suitable for content from unknown origin.
Local Intranet	Default policy permission set within an enterprise.
Everything	All standard (built-in) permissions, except permission to skip verification.
FullTrust	Full access to all resources.

For more information, see Named Permission Sets.

Evidence

Evidence is the information that the common language runtime uses to make decisions based on security policy. Evidence indicates to the runtime that code has a particular characteristic and can include application directory, publisher, site, and URL. For more information, see Evidence.

Application-Domain Hosts

Each .NET Framework application runs in an application domain under the control of a host that creates the application domain and loads assemblies into it. Application domains can include:

Browser hosts. Run code within the context of a Web site.
Custom-designed hosts. Create domains and load assemblies into domains, including dynamic assemblies.
Server hosts, Run code that handles requests submitted to a server.
Shell hosts. Launch applications (.exe files) from the shell.

This table lists tasks associated with application domains:

To	See
Create an application domain	How to: Create an Application Domain
Set application-domain-level security policy	Setting Application Domain-Level Security Policy
Configure an application domain	How to: Configure an Application Domain
Call functions in a specific application domain	Calling Functions in a Specific Application Domain
Retrieve setup information from an application domain	Retrieving Setup Information from an Application Domain
Unload an application domain	How to: Unload an Application Domain

For more information, see AppDomain, Application Domain Hosts and Programming with Application Domains.

Share via