Code-Access Permissions and Security (C# and Visual Basic(
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.
In .NET Framework 4, security transparency is the default enforcement mechanism. Security transparency separates code that runs as part of the application from code that runs as part of the infrastructure. For more information, see Security-Transparent Code.
There are major differences between the code access security system in .NET Framework 4 and that of earlier versions. Security policy is no longer applied to applications. All applications that can be run from the desktop are now executed as full-trust applications. This includes applications on the computer and applications that can be run from a network share. Partially trusted applications must be run in a sandbox, which determines their grant set. The permission system continues to be used, but it is transcended by security transparency rules. For information about these changes, see Security Changes in the .NET Framework 4.
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.
Access to resources in ASP.NET-hosted environments.
Access to the System.DirectoryServices classes.
Access to Domain Name System (DNS) servers on a network.
Reading from or writing to environment variables.
Reading from or writing to event log services.
Reading from or writing to files by means of an Open dialog box.
Reading from or writing to files or directories.
Reading from or writing to files or directories in isolated storage.
Access to message queues through the managed Message Queuing (also known as MSMQ) interfaces.
Accessing ODBC (Open Database Connectivity) data sources.
Accessing databases using OLE DB.
Accessing Oracle databases.
Accessing performance counters.
Determining information about a type at run time.
Reading from, writing to, creating, or deleting registry keys and values.
Executing, asserting permissions, calling into unmanaged code, skipping verification, and other security-related rights.
Accessing running or stopped services.
Making or accepting connections on a transport address.
Accessing SQL databases.
Accessing user interface functionality.
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.
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.
The following table lists tasks associated with permissions and security.
Request permission for a named permission set
Request XML-encoded permissions
Perform an imperative security check
Perform a declarative security check
Override a security check
Share a library with partially trusted code
Require full trust for types within an AllowPartiallyTrustedCallersAttribute assembly