NET Security Primer for a SSRS Administrator

Although the details of .NET security are outside the scope of this book, a brief security overview will help you to better understand the security of SSRS assemblies. You can find more security- related topics in the Microsoft .NET Framework documentation (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/netframesecover.asp.

By default, custom assemblies are granted Execute permission in Reporting Services. The Execute permission set enables code to run, but not to use protected resources. For example Execute permission allows string manipulations, but not access to the file system.

The worst outcome of a malicious call to the assembly with Execute permission is a potential denial of service attack in which a malicious assembly causes excessive CPU and memory use, thereby impacting performance of other software components running on the computer on which such an assembly is installed.

Note

When a developer calls a .NET namespace, it might not be immediately clear if the Execute permission is sufficient. For example, the GetExecutingAssembly() method requires FileIOPermission . However, it might be logically concluded that the Execute permission is sufficient because the method retrieves information about the assembly it is called from and the assembly should be loaded in the memory. It so happens that the call to this method does PathDiscovery to check the assembly's path and thus requires FileIOPermission .

After an assembly is enabled for additional permissions, the impact of a malicious call could be more dramatic, such as data loss.

.NET common language runtime (CLR) employs code access security, which allows an administrator to assign permissions to an assembly. When an assembly makes a call to a protected resource (for example, file IO), the runtime checks if an assembly has appropriate permissions to do so. During the call, CLR evaluates all the assemblies in the call stack for permissions. This prevents an AssemblyA with restricted permissions (such as Execute ) to call an AssemblyB with less restrictions to perform an operation on a protected resource.

An administrator sets the security policy by editing XML configuration files. SSRS has three configuration files: rssrvpolicy.config , and rsmgrpolicy.config , rspreviewpolicy.config (outlined in Table 23.2). Depending on the end goal, one or more files should be edited.

Tip

An administrator should always create a backup of SSRS configuration files prior to any modifications.

Table 23.2. SSRS Configuration Files

Filename	Location(Default Installation)	Description
rssrvpolicy.config	C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer	The Report Server policy configuration file. This file contain security policies for the Report Server and affects execution of the following: 1. Custom expressions and assemblies deployed to a Report Server 2. Custom data, delivery, rendering, and security extensions deployed to the Report Server
rsmgrpolicy.config	C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportManager	The Report Manager policy configuration file. These security policies affect all assemblies that extend Report Manager; for example, subscription user -interface extensions for custom delivery.
rspreviewpolicy.config	C:\Program Files\Microsoft Visual Studio 8\Common7\ IDE\PrivateAssemblies\ RSPreviewPolicy.config	The Report Designer stand alone preview policy configuration file. This file contains security policies for Report Designer and affects the following: 1. Execution of custom expressions and assemblies in reports during preview in Report Designer 2. Execution of custom extensions, such as data-processing extensions, that are deployed to Report Designer

Tip

Use Microsoft Knowledge Base Article KB842419 (http://support.microsoft.com/?kbid=842419) for the step-by-step process of working with security permission settings in SSRS.

Administrators can edit configuration files manually, using any text editor (possible, but not recommended method) or employ the help of the .NET Framework Configuration Utility ( mscorcfg .mcs) .

Tip

Use the .NET Framework Configuration Utility ( mscorcfg.mcs ) to simplify permission creation and minimize a chance of malformed XML.

The easiest way to start this utility is from Control Panel, Administrative Tools, .NET Framework 2.0 Configuration. This tool is shown in Figure 23.5.

Figure 23.5. .NET Framework Configuration Utility.

The .NET Framework Configuration Utility edits the computer's security policy file stored located at (make sure to adjust path for the proper version of.NET) C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\security.config .

Instead of editing SSRS configuration files manually, an administrator can use the .NET Framework Configuration Utility and then copy the <PermissionSet> and <CodeGroup> from the security.config file to an appropriate SSRS configuration file.

Tip

To simplify finding <PermissionSet> and <CodeGroup> elements that need to be copied to the SSRS configuration file, an administrator can choose to create a permission set and a code group with easily distinguishable names , which could be as simple as PermissionSet and MyCodeGroup . Then, an administrator can use a text editor to search and copy the appropriate permissions.

There are three levels of security policies:

• Enterprise level is the highest and applies to the entire enterprise.

• Machine policy applies to all code run on that computer.

• User policy applies the currently logged-in user.

A lower level can place further restrictions on the policy settings from the highest level, but cannot expand the permissions. As a result, code is granted the minimum set of permissions granted by any of the levels.

To set permissions for an assembly, follow these steps:

1.	Create a permission set or use one of the predefined sets, such as Execution (each assembly in SSRS gets this set by default). Additional permission sets are FullTrust , Internet , None , and more.
2.	Create a code group that maps a permission set to an assembly or, more specifically uses Membership Condition to perform this mapping.

Figure 23.6 shows security permission configuration objects (configured as an XML in .config files) for an assembly.

Figure 23.6. Assembly security permission objects.

Each permission set contains zero or more permissions. A permission is a logical subdivision of system functionality (or access control to a protected resource). Examples of permissions are Registry (controls access to the computer's registry, as a whole or by an individual key), File IO (controls access to a single file or a whole file system), Printing (controls access to printing resources), SQL Client (controls access to SQL Servers), and more.

Each permission supports one or more properties that provide more details for a permission. For example, the File IO permission allows specifying an individual file that can be accessed for either one or all of the following: Read , Write , Append , and Path Discovery . Security is somewhat an obscure permission because its attributes are presented as security permissions.

Some of the permissions that Security allows to specify are Enable Assembly Execution ( Execute permission) and Assert Any Permission That Has Been Granted . Assert Any Permission That Has Been Granted in turn enables an assembly to do exactly what the permission implies, that is, to assert security permissions, such as File IO .

A code group uses membership condition to associate an assembly with a permission set. The most commonly used membership conditions are of URL and Strong Name type. URL membership uses a path to an assembly and Strong Name uses exactly what it implies, the strong name of an assembly.

Note

Some literature uses the term "evidence" to refer to the membership condition type.

When SSRS calls an assembly, the assembly, in turn, tries to access a protected resource the .NET CLR checks if administrators have set up the appropriate permissions. The CLR then checks the call stack to evaluate permissions for each assembly and makes sure that the minimum combined permission is applied. This prevents a malicious assembly with Execute permission to do anything bad by calling another assembly with FullTrust permission.