- File dialog (read-only)
- Isolated storage
- Security permission to execute
- UI permission to create safe top-levels windows and use the clipboard
.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:
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.
Internet Explorer security and managed execution
Application domain hosts
Default security policy
Creating your own code access permissions
Microsoft .NET: Implement a custom Common Language Runtime host for your managed app
Host secure, lightweight client-side controls in Microsoft Internet Explorer
Article ID: 311301 - Last Review: Jun 19, 2014 - Revision: 1