The Interaction of App Domains with Stack Walks

for RuBoard

In the interests of clarity, the stack walk algorithm presented thus far has been simplified somewhat. There is one further factor that can alter the outcome of a stack walk ”the interaction of the app domain(s) in which the current thread is executing.

An app domain (short for application domain) can be thought of as a process within a process. Multiple app domains can exist within a single Win32 process and provide the same sort of separation between managed tasks that processes provide between unmanaged tasks . Each app domain is isolated from the others (they load their own set of assemblies and cross-domain communication requires the use of the remoting subsystem). This segregation means that should a single app domain fail, it is possible to shut down just that domain without impacting the others. The hierarchy of process, app domains, and assemblies is illustrated in Figure 7.6.

Figure 7.6. Major components of the .NET Framework model.

graphics/07fig06.gif

How app domains are utilized within the .NET Framework depends largely on the hosting environment. The Windows shell creates a single initial app domain and leaves the rest up to the application itself, whereas a database system might create an app domain for each user currently connected, or even each separate query.

The aspect of app domains that makes them interesting from our perspective is that it is also possible to grant them permissions in the same manner as permissions are normally granted to assemblies. For example, this facility is used by Internet Explorer when displaying a Web page containing references to managed objects. The objects themselves are granted permissions based on the identity of the assembly that owns them, but Internet Explorer also wants to assign an identity and permissions to the Web page in which they're embedded. Thus, an app domain is created for each Web page and provided with identity evidence (in the form of the Web page URL) so that the normal security policy mechanism can compute an appropriate set of granted permissions.

So how does this affect a stack walk? At any given instant, each thread running within a .NET Framework process is executing within the context of a single app domain. If a method call is made on an object that resides in a different app domain, the remoting system will transparently transition the thread into the context of that app domain (and transition the thread back again when the call completes). This transition leaves its mark on the thread's stack in much the same way that a normal method call would. An example of our revised view of a stack is shown in Figure 7.7.

Figure 7.7. A typical stack with app domain transitions.

graphics/07fig07.gif

When the security system finds an app domain transition on the stack, it treats it as though it was an assembly transition. That is, the grant set is fetched and inspected to determine whether it supports the demand being made. If so, the stack walk proceeds; otherwise , the stack walk is terminated with a security exception.

Although this check is performed when an app domain transition is found (and the transition describes the app domain from which the thread came), the check performed is against the grant set of the app domain into which the thread transitioned ”that is, the app domain in which the preceding frames were executing. We know the initial app domain (the one in which the thread was executing at the time the stack walk was initiated) because the .NET Framework runtime tracks the current app domain as an attribute of each thread, and the security system can query this information. Figure 7.8 is the diagram from Figure 7.7, this time with the app domains marked for each frame.

Figure 7.8. Integrating the app domain transition data into the stack trace.

graphics/07fig08.gif

It's important that the security system performs the check against an app domain's grant set after the checks against the stack frames that executed within that app domain. This is because an app domain might have a fairly restrictive grant set (in the Internet Explorer case, there's a good chance the app domain is associated with a Web page loaded from the Internet zone, whose policy is likely to assign minimal permissions to), but individual assemblies within the app domain may be granted a higher level of trust.

Consider the example of a Web page loaded from the Internet that hosts a control that needs to access the user's local file system. The control is contained within an assembly also loaded from the Internet, but it provides additional evidence (such as a strong name or an Authenticode certificate) that allows the policy system to assign it more trust ( specifically , unrestricted FileIOPermission ).

If the control tries to write a file on the user's disk and the permissions of the app domain in which the control is running were checked first, the request would always fail, because the app domain is associated with the Web page and the Web page hasn't been granted FileIOPermission .

Recall, however, that the stack walk algorithm will normally walk the entire stack before declaring success. So, even after we reverse the order in which the checks are performed, the file operation will ultimately still be denied . But now the control can do something about it; this is a perfect use for the Assert operation.

The control can simply Assert FileIOPermission prior to making any file system calls, preventing the lower permission level of the hosting Web page from coming into play at all, as shown in Figure 7.9.

Figure 7.9. Overriding Web page permissions.

graphics/07fig09.gif

Note that unless the creator of an app domain explicitly associates evidence with it, app domains are considered to have no security implications whatsoever. Such app domains are not considered at all during stack walks. The default app domain created when launching an executable assembly from the Windows shell is an example of an app domain with no associated evidence and, hence, no grant set.

for RuBoard


. NET Framework Security
.NET Framework Security
ISBN: 067232184X
EAN: 2147483647
Year: 2000
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net