Depending on the deployment method, you have numerous ways to specify what security level to grant a CLR assembly. All of them demand that you specify one of three permission sets:
Safe Assembly can perform local data access and computational tasks only.
External_Access
Assembly can perform local data access and computational tasks and also
access the network, the file system, the registry, and environment
variables. Although External_Access is less restrictive than Safe, it still safeguards server stability.
Unsafe Assembly has unrestricted permissions and can even call unmanaged code. This setting can significantly compromise SQL Server security; only members of the sysadmin role can create (load) unsafe assemblies. Also note the TRUSTWORTHY property must be set to ON for the database into which the unsafe assembly will be loaded, and the dbo must have UNSAFE ASSEMBLY permission (or the assembly must be specially signed). There is commented code at the top of the CreateObjects.sql script that sets the TRUSTWORTHY property to ON for the AdventureWorks2012 database.
When you deploy an assembly from Visual Studio, its security level is set to Safe by default. To change it, double-click the Properties
node in the Solution Explorer, click the SQLCLR tab in the resulting
property sheet designer and then select SAFE, EXTERNAL_ACCESS, or
UNSAFE from the Permission Level combo box, as shown in Figure 1.
To specify an assembly’s permission set using T-SQL, simply specify SAFE, EXTERNAL_ACCESS, or UNSAFE within the “WITH PERMISSION_SET” clause of the CREATE ASSEMBLY statement. Recall that our example used the default SAFEsetting in this clause.
Finally, in the SSMS New Assembly dialog box and the Assembly Properties dialog box, you can select Safe, External Access, or Unrestricted from the Permission Set combo box. The last of these three options is equivalent to selecting the UNSAFE permission set in Visual Studio or T-SQL.
