How Internet Explorer determines permissions for .NET Framework assemblies (311301)


The information in this article applies to:

  • Microsoft .NET Framework SDK 1.0
  • Microsoft Internet Explorer (Programming) 6.0
  • Microsoft Internet Explorer (Programming) 5.5
This article was previously published under Q311301

SUMMARY

Web-based applications can use Microsoft Internet Explorer 5.5 and later to download and run Microsoft .NET Framework assemblies. This article describes how Internet Explorer determines the permissions that are granted to assemblies.

MORE INFORMATION

.NET Framework assemblies that are deployed from an intranet are typically granted the default Intranet Permissions set. This set allows code to perform only a very limited set of functions. These functions include the following:
  • File dialog (read-only)
  • Isolated storage
  • Security permission to execute
  • UI permission to create safe top-levels windows and use the clipboard
Your managed control may not run in Internet Explorer, unless ActiveX controls and scripting are turned on.

.NET Framework Service Pack 1 (or V1 for those localized versions that receive this change) will set a new default security policy, in which managed code cannot be downloaded from the Internet zone.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

317399 .NET Framework change in default machine level security policy

The Common Language Runtime (CLR) is designed to support a variety of different .NET Framework applications. Currently, each application type requires a piece of code to start. This code is referred to as a CLR host. The responsibility of a host is to load the correct version of the CLR into a process, define the application domains within the process, and run user code within those domains.

To provide an isolated environment for each type of application, the CLR supports several different runtime hosts, as well as Internet Explorer. All CLR hosts must start with an unmanaged stub. For this purpose, the .NET Framework provides a set of unmanaged application programming interfaces (APIs). The application hosts can use these unmanaged APIs to get the CLR running.

The .NET Framework includes two components that handle the .NET Framework components in Internet Explorer. The first component, Mscorie.dll, contains a Multipurpose Internet Mail Extensions (MIME) Type Filter. This filter hooks into Internet Explorer and monitors all incoming data streams with the MIME type application/octet-stream. A primary role of this startup shim is to examine the incoming stream to see whether or not the stream is a managed code. If the filter determines that the incoming data is not a managed code, the filter allows Internet Explorer to handle the data the way that it did formerly.

If the MIME Type Filter determines that the stream is a .NET Framework module, the filter loads the second component. The second component is a managed assembly named IEHost. The IEHost calls the CorBindToRuntimeByCfg API to load the CLR into a process. The IEHost also calls IEManager, a security manager that creates an application domain within the process. After the host creates and configures the application domain, the host calls into its Factory Object to create an instance of the requested .NET Framework Object and to load and run user code within this application domain.

The Internet Explorer host defines an application per Web site by default. The root directory of the site is considered the root directory for the application. The host has a high degree of control over the permissions that the code receives when it runs in a specified application domain. All code that runs in the Common Language Runtime must be part of an assembly. Every application that targets the CLR must interact with the security system of the runtime. When an application runs, the runtime automatically evaluates the application. The runtime also gives the application a set of permissions. These permissions are based on the evidence that the application provides and on the security policy. Common forms of evidence for IEHost include StrongName, URL, Site, Zone, and Publisher.

The CLR allows the code to perform only those operations that the code has permission to perform. The .NET Framework contains a permission object for every resource that is available on a user's computer. These resources include File I/O, Web access, unmanaged code execution, and more. The runtime uses these permission objects to enforce restrictions on the managed code.

To grant permissions to the .NET Framework code, administrators or power users group the permissions into a permission set. The permission set then is applied to a code group. A particular assembly (the basic unit of code for granting security permissions) is a member of a code group if it satisfies the membership condition of the code group.

To view the default permissions that are given to .NET assemblies, use the .NET Framework Configuration Tool (Mscorcfg.msc). You also can use this tool to view and configure security policy. Administrators can define custom-named permission sets, as long as their names are different from the built-in named permission sets.

back to the top

REFERENCES

Microsoft .NET Framework 1.0 addendum

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/framewrkaddend.asp

Internet Explorer security and managed execution

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconinternetexplorersecuritymanagedexecution.asp

Application domain hosts

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconapplicationdomainhosts.asp

Default security policy

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondefaultsecuritypolicy.asp

Code groups

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcodegroups.asp

Evidence

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconevidence.asp

Creating your own code access permissions

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcreatingyourowncodeaccesspermissions.asp

Microsoft .NET: Implement a custom Common Language Runtime host for your managed app

http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/03/clr/TOC.asp

Host secure, lightweight client-side controls in Microsoft Internet Explorer

http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx

back to the top
Modification Type:MajorLast Reviewed:6/9/2006
Keywords:kbinfo kbSecurity KB311301
©2004 Microsoft Corporation. All rights reserved.