Datasheet

be discussed in more detail. However, trust levels are introduced at this point of the discussion because
application domain initialization is where ASP.NET loads and applies the appropriate trust level infor-
mation. After you understand how ASP.NET trust levels work, the knowledge that an ASP.NET trust
level is converted into and applied as an application domain policy very early in the lifetime of an appli-
cation domain helps to explain some of the more obscure security errors customers may encounter.
In practice, many folks are probably unaware of ASP.NET’s ability to apply an application domain policy,
and instead their websites run in full trust. Partly this is due to the fact that both ASP.NET 1.1 and
ASP.NET 2.0 set the ASP.NET trust level to full by default. Full trust means that the .NET Framework
allows user-authored code the freedom to call any API without any security restrictions.
After ensuring that the required directories are available, ASP.NET checks the trust level setting in
configuration that is found in the
<trust /> configuration section. Based on the configured trust level,
ASP.NET loads the appropriate trust policy configuration file from the following directory:
%windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG
The contents of the trust policy file are modified in memory to replace some of the string replacement
tokens that are present in the physical policy files. The end result of this processing is a reference to a
System.Security.Policy.PolicyLevel instance that represents the desired application domain
security policy. ASP.NET then applies the policy level to the application domain by calling
System.AppDomain.CurrentDomain.SetAppDomainPolicy.
This processing is one of the most critical steps taken during application domain initialization because
prior to setting the application domain’s security policy, any actions taken by ASP.NET are running in
full trust. Because a full trust execution environment effectively allows managed code to call any API
(both managed APIs and native APIs), ASP.NET intentionally limits the initialization work it performs
prior to setting the application domain’s security policy. Looking back over the initialization work that is
completed prior to this step, you can see that ASP.NET has not actually called any user-supplied code up
to this point. All of the initializations are internal-only checks and involve only framework code.
With the application domain’s permission policy established though, any subsequent initialization work
(and of course all per-request processing) that calls into user-supplied code will be restricted by the
application domain policy that ASP.NET has applied based on the contents of a specific ASP.NET trust
policy configuration file.
An important side effect from establishing the trust level is that any calls into the configuration system
from this point onwards are subject to the security restrictions defined by the trust level. Configuration
section handlers are defined in
machine.config as well as web.config within the <configSections
/>
configuration element. By default a number of configuration section handlers are registered in the
configuration files.
Because ASP.NET establishes the bin directory as one of the locations for resolving assemblies, it is possible
to author configuration section handlers that reside within assemblies deployed to the bin directory. Because
the application domain CAS policy has been set, any initialization logic that a user-authored configuration
section handler executes when it loads is restricted to only those operations defined in the associated
ASP.NET trust policy file. For example, in an ASP.NET application that runs at anything other than full trust,
user code cannot call into Win32 APIs. As a result, in a partially trusted ASP.NET application, a web server
18
Chapter 1
04_596985 ch01.qxp 12/14/05 7:46 PM Page 18