.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.