Using Appdomains to Secure Unmanaged Clients

for RuBoard

Appdomains serve another vital role in securing a hosted environment. Normally, code access security is enforced on a per-assembly basis (each assembly is assessed by the policy system to determine the level of trust to be granted and assigned permissions accordingly ). But what happens when control is coming from a partially trusted environment outside the scope of the runtime?

Take the example of script running in an HTML Web page within the user 's browser. This simple, non-.NET Framework aware script (JavaScript or VBScript, for example) can nevertheless instantiate and invoke method calls on managed objects because all managed objects are marked , by default, as safe for scripting (as long as the object is instantiated using the correct new <OBJECT> syntax, old style instantiations will treat managed objects as ActiveX controls). So what stops such a script from creating a FileStream object and writing to the user's disk? The demand for FileIOPermission wouldn't seem to help, because the real caller (the script itself) is not managed and will not appear on the stack. In fact, from the security stack walk perspective, there will appear to be no callers of the FileStream constructor at all, and the demand will succeed immediately (remember security stack walks are looking for negative information, that is, the first method that belongs to an assembly that is not granted the permissions demanded).

To avoid this problem, the browser (which is an example of a .NET Framework host) will create an appdomain for the Web page under which the script is running. The appdomain will have the URL of the Web page associated with it as security evidence, and this allows the .NET Framework security system to process the appdomain through security policy as if it were an assembly ”granting permissions to it in the process.

As we discussed in Chapter 7, "Walking the Stack," security stack walks take appdomain transitions into account when following the call chain. So the appdomain created to run code invoked by script acts as a place holder for the trust placed in that script by the runtime. You can imagine the appdomain as being a substitute for the virtual assembly represented by the script. Figure 10.3 depicts the stack in such a situation.

Figure 10.3. Using an appdomain as an assembly place holder.

graphics/10fig03.gif

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