Monday, June 29, 2009

CLR Integration Code Access Security

The common language runtime (CLR) supports a security model called code access security for managed code. In this model, permissions are granted to assemblies based on the identity of the code. For more information, see the "Code Access Security" section in the .NET Framework software development kit.

The security policy that determines the permissions granted to assemblies is defined in three different places:

  • Machine policy: This is the policy in effect for all managed code running in the machine on which SQL Server is installed.
  • User policy: This is the policy in effect for managed code hosted by a process. For SQL Server, the user policy is specific to the Windows account on which the SQL Server service is running.
  • Host policy: This is the policy set up by the host of the CLR (in this case, SQL Server) that is in effect for managed code running in that host.

The code access security mechanism supported by the CLR is based on the assumption that the runtime can host both fully trusted and partially trusted code. The resources that are protected by CLR code access security are typically wrapped by managed application programming interfaces that require the corresponding permission before allowing access to the resource. The demand for the permission is satisfied only if all the callers (at the assembly level) in the call stack have the corresponding resource permission.

The set of code access security permissions that are granted to managed code when running inside SQL Server is the intersection of the set of permissions granted by the above three policy levels. Even if SQL Server grants a set of permissions to an assembly loaded in SQL Server, the eventual set of permissions given to user code may be restricted further by the user and machine-level policies.

The set of code access security permissions granted to assemblies by the SQL Server host policy level is determined by the permission set specified when creating the assembly. There are three permission sets: SAFE, EXTERNAL_ACCESS and UNSAFE.

SQL Server supplies a host-level security policy level to the CLR while hosting it; this policy is an additional policy level below the two policy levels that are always in effect. This policy is set for every application domain that is created by SQL Server. This policy is not meant for the default application domain that would be in effect when SQL Server creates an instance of the CLR.

The SQL Server host-level policy is a combination of SQL Server fixed policy for system assemblies and user-specified policy for user assemblies.

The fixed policy for CLR assemblies and SQL Server system assemblies grants them full trust.

The user-specified portion of the SQL Server host policy is based on the assembly owner specifying one of three permission buckets for each assembly. For more information about the security permissions listed below, see the .NET Framework SDK.


Only internal computation and local data access are allowed. SAFE is the most restrictive permission set. Code executed by an assembly with SAFE permissions cannot access external system resources such as files, the network, environment variables, or the registry.

SAFE assemblies have the following permissions and values:

See full detail: