Sugerir traducción

Otros han sugerido:

No hay más sugerencias.

MSDN Magazine > Inicio > Todos los números > 2009 > MSDN Magazine Noviembre 2009 > Exploración del modelo de seguridad de .NET Fra...

Ver contenido: en paralelo

La información aquí ofrecida es contenido traducido automáticamente que los miembros de la comunidad pueden editar. Quienes deseen contribuir a mejorar la traducción, pueden hacer clic en el vínculo “editar” asociado a cualquiera de los siguientes enunciados.

CLR INSIDE OUT

Exploring the .NET Framework 4 Security Model

Andrew Dai

The .NET Framework 4 introduces many updates to the .NET security model that make it much easier to host, secure and provide services to partially trusted code. We’ve overhauled the complicated Code Access Security (CAS) policy system, which was powerful but difficult to use and even more difficult to get right. We’ve also improved upon the Security Transparency model, bringing much of the Silverlight improvements (which I talked about last October: msdn.microsoft.com/magazine/cc765416.aspx) in security enforcement to the desktop framework. Finally, we’ve introduced some new features that give host and library developers more flexibility over where their services are exposed. With these changes, the .NET Framework 4 boasts a simpler, improved security model that makes it easy for hosts and libraries to sandbox code and libraries to safely expose services.

A Background in .NET Framework Security

Before diving into any particular feature, it helps to have a little background on how security in the .NET Framework works. Partially trusted code is restricted by the permissions it has, and different APIs will require different permissions to successfully be called. The goal of CAS is to make sure that untrusted code runs with appropriate permissions and can’t do anything beyond its permissions without authorization.

We can think of the .NET security model as comprising three parts. Specific improvements have been made in each area, and the rest of this article is organized according to these three fundamental sections:

Policy—Security policy determines which permissions to give a particular untrusted assembly or application. Managed code has Evidence objects associated with it, which can describe where the code is loaded from, who published it and so on. Evidence can be used to determine which permissions are appropriate; the result is called a permission grant set. The .NET Framework has traditionally used CAS policy as a machine-wide mechanism to govern this. As mentioned before, CAS policy has been overhauled in favor of giving hosts more flexibility over their own security policy and unhosted code parity with native code.
Sandboxing—Sandboxing is the actual process of restricting assemblies or applications to a given permission grant set. The preferred way to sandbox is to create a sandboxing application domain containing a permission grant set for loaded assemblies and an exemption list for specific library assemblies (these are given full trust). With the obsoletion of CAS policy, partial trust code always gets sandboxed this way in .NET Framework 4.
Enforcement—Enforcement refers to the mechanism that keeps untrusted code restricted to its sandbox. Proper use of enforcement APIs prevents one untrusted assembly from simply calling an API in a different, more-trusted assembly and exercising greater permissions that way. It also allows host and library developers to expose controlled, limited access to elevated behavior and provide meaningful services to partially trusted code. The Level 2 Security Transparency model makes it much easier to safely do this.

The .NET security model has always been of particular importance to host and library developers (who often go hand in hand). Examples of the .NET security model are ASP.NET and SQL CLR, which both host managed code within controlled environments and restricted contexts. When a host like these wants to load a partially trusted assembly, it creates a sandboxed application domain with the appropriate permission grant set. The assembly is then loaded into this sandboxed domain. The host also provides library APIs that are fully trusted but callable from the hosted code. The libraries are also loaded into the sandboxed domain, but are explicitly placed on the exemption list mentioned earlier. They rely on the .NET Framework’s enforcement mechanisms to ensure that access to its elevated abilities is tightly controlled.

For most managed application developers, this is all magic that is happening at the framework level—even developers writing code that will be run in a sandbox don’t need to know all the details of how the security model works. The framework ensures sandboxed code is limited to using APIs and abilities that the host provides. The .NET security model and CAS have long been the realm of enterprise administrators and host and library developers; for them, we’ve made things easier than ever.

Policy

CAS policy has been provided since the beginning of the .NET Framework to give machine and enterprise administrators a way to fine-tune what the runtime considered trusted or untrusted. While CAS policy was very powerful and allowed for very granular controls, it was extremely difficult to get right and could hinder more than help. Machine administrators could lock certain applications out of needed permissions (described in the next major section, Sandboxing), and many people wondered why their applications suddenly stopped working once they decided to put them on a network share. Furthermore, CAS policy settings didn’t move forward from one version of the runtime to another, so the elaborate custom CAS policy that someone set up in .NET Framework 1.1 had to be redone by hand for .NET Framework 2.0.

Security policy could be split into two scenarios: security policy for hosted code and security policy for the machine or enterprise. Regarding machine policy, the Common Language Runtime security team has decided that the runtime was the wrong place to govern it, as native code was obviously not subject to its restrictions. While it makes sense for hosts to be able to determine what their hosted code can do, unhosted exes that are simply clicked or run from the command line should behave like their native counterparts (especially since they look identical to the users running them).

The correct place for global security policy is at the operating system level, where such a policy would apply to native and managed code equally. Therefore, we’re encouraging machine administrators to look at solutions like Windows Software Restriction Policies and disabling machine-wide CAS policy resolution by default. The other scenario, security policy for hosted code, is still very much valid in the managed code world. Host security policy is now easier to govern, as it will no longer clash with an arbitrary machine policy.

What This Means for You

For one, all unhosted managed code runs as fully trusted by default. If you run an .EXE from your hard drive or a network share, your app will have all the abilities a native app running from the same place would have. Hosted code, however, is still subject to the security decisions of the host.(Note that all the ways that code can arrive via the Internet are hosted scenarios—ClickOnce applications, for example—so this does not mean that code running over the Internet is fully trusted.)

For many applications, these changes are mostly in the background and will have no perceived effect. Those that are affected by the change may run into two issues. The first is that certain CAS policy-related APIs are deprecated, many having to do with assembly loads (so read on if you do this at all). Second, and affecting fewer people (primarily hosts), will be the fact that heterogeneous application domains (which are described in the Sandboxing section) aren’t available by default.

But I’m not doing any of this! How do I just make it work?

Perhaps you’ve run into an error or obsoletion message that looked something like this:

This method [explicitly/implicitly] uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see [link to MSDN documentation] for more information.

For compatibility reasons, we’ve provided a configuration switch that allows a process to enable CAS policy resolution on it. You may enable CAS policy by placing the following in your project’s app.config file:

<configuration>
   <runtime>
      <!-- enables legacy CAS policy for this process -->
      <NetFx40_LegacySecurityPolicy enabled="true" />
   </runtime>
</configuration>

The following section describes where to start looking for migration, if the exception is being thrown from your own code. If it isn’t, then the configuration switch is the way to go and the following section shouldn’t apply directly to you.

Affected APIs

Affected APIs can be divided into two groups: those that are explicitly using CAS policy and those that are implicitly using it. Explicit usages are obvious—they tend to reside in the System.Security.Policy.SecurityManager class and look something like SecurityManager.ResolvePolicy. These APIs directly call or modify the machine’s CAS policy settings, and they have all been deprecated.

Implicit usages are less obvious—these tend to be assembly loads or application domain creations that take evidence. CAS policy is resolved on this evidence, and the assembly is loaded with the resulting permission grant set. Since CAS policy is off by default, it doesn’t make sense to try to resolve it on this evidence. An example of such an API is Assembly.Load(AssemblyName assemblyRef,Evidence assemblySecurity).

There are a couple of reasons why such an API would be called:

Sandboxing—Perhaps you know that calling that Assembly.Load overload with zone evidence from the Internet will result in that assembly being loaded with the Internet named permission set (unless, that is, an administrator changed that evidence mapping for this particular machine or user!).
Other parameters on the overload—Maybe you just wanted to get to a specific parameter that existed only on this overload. In this case, you might’ve simply passed null or Assembly.GetExecutingAssembly().Evidence for the evidence parameter.

If you’re trying to sandbox, the Sandboxing section describes how to create a sandboxed application domain restricted to the Internet named permission set.. Your assembly could then be loaded into that domain and be guaranteed to have the permissions you intended (that is, not subject to the whims of an administrator).

In the second scenario, we’ve added overloads to each of these APIs that expose all necessary parameters but don’t expose an evidence parameter. Migration is a simple matter of cutting out the evidence argument to your calls. (Note that passing null Evidence into an obsolete API still works as well, as it doesn’t result in CAS policy evaluation.)

One additional thing to note is that if you’re doing an assembly load from a remote location (that is, Assembly.LoadFrom(“http://...”)), you’ll initially get a FileLoadException unless the following configuration switch is set. This was done because this call would’ve sandboxed the assembly in the past. With CAS policy gone, it is fully trusted!

<configuration>
   <runtime>
      <!-- WARNING: will load assemblies from remote locations as fully
         trusted! -->
      <loadFromRemoteSources enabled="true" />
   </runtime>
</configuration>

Another way to do this, without turning this switch on for the whole process, is to use the new Assembly.UnsafeLoadFrom API, which acts like LoadFrom with the switch set. This is useful if you only want to enable remote loads in certain places or you don’t own the primary application.

With machine-wide CAS policy out of the picture, all examination of assembly evidence and decisions regarding appropriate permission sets is left up to hosts of managed code. Without a complicated system on top of it interfering with its security decisions (aside from any OS security policy), a host is free to assign its own permissions. Now it’s time to assign those permissions to partial trust assemblies.

Sandboxing

Via a host’s security policy, we can determine the correct permission grant set to give to a partial trust assembly. Now we need a simple, effective way to load that assembly into an environment that is restricted to that particular grant set. Sandboxing, particularly using the simple sandboxing CreateDomain overload, does just that.

Sandboxing in the Past

With the old CAS policy model, it was possible to create a heterogeneous application domain, where every assembly in the domain had its own permission set. An assembly load with Internet zone evidence could result in two or more assemblies at different partial trust levels being loaded into the same domain as the full trust assembly doing the loading. Furthermore, the application domain could have its own evidence, giving it its own permission set.

There are several issues with this model:

The permission set granted to an assembly is dependent on CAS policy, as several policy levels are intersected to compute the final permission set. Therefore, it is possible to end up with fewer permissions than intended.
Similar to the previous point, evidence evaluation on an assembly is done by CAS policy, which could differ across machines, users and even versions of the runtime (CAS policy settings didn’t move forward with new versions of the runtime). Therefore, it wasn’t always obvious what permission grant set an assembly was getting.
Partial trust assemblies are not usually examined for security hardening, making “middle trust” assemblies vulnerable to “lowest trust” assemblies. Assemblies are freely and easily able to call each other, so having many of them with different abilities becomes problematic from a security perspective. Can someone be certain that every combination of calls from assemblies at different trust levels is secure? Is it absolutely safe to cache information from a middle trust layer?

Because of these issues, we introduced the concept of a homogeneous application domain, which contains only two permission grant sets (partial trust and full trust) and is extremely simple to create and reason about. Homogeneous domains, and how to create them, are described later in this section.

Another popular mechanism for sandboxing was the use of PermitOnly and Deny, which are stack walk modifiers that list specific allowed permissions (and nothing more) and disallow specific permissions, respectively. It seemed useful to say, “I only want callers with permissions x and y to be able to call this API,” or, “as an API, I want to deny permission to all my callers.” However, these modifiers did not actually change the permission grant set of a particular assembly, which meant that they could be asserted away because all they did was intercept demands. An example of this in action is shown in Figure 1.

Figure 1 A Call Stack Representing an Attempt at Sandboxing with Deny

Without the red Assert, the demand hits the Deny and the stack walk is terminated. When the red Assert is active, however, the Deny is never hit, as Untrusted has asserted the demand away. (Notes: Call stack is growing down. APIs do not represent actual APIs in the framework.) For this reason, Deny is deprecated in the .NET Framework 4, because using it is always a security hole (PermitOnly is still around because it can be legitimately used in a few corner cases, but is generally discouraged). Note that it can be reactivated using the NetFx40_LegacySecurityPolicy switch, mentioned in the policy section above.

Sandboxing Today

For the .NET Framework, the unit of isolation we use is the application domain. Each partial trust application domain has a single permission grant set that all assemblies loaded into it get, except for the ones specifically listed on the full trust exemption list or loaded from the Global Assembly Cache. Creating this domain is very simple — the .NET Framework provides a simple sandboxing API that takes in everything you need to create the domain:

AppDomain.CreateDomain( string friendlyName,  
                        Evidence securityInfo,                         
                        AppDomainSetup info,                         
                        PermissionSet grantSet,                         
                        params StrongName[] fullTrustAssemblies);

Where the parameters are:

friendlyName—The friendly name of the application domain.
securityInfo—Evidence associated with the application domain. This isn’t used for CAS policy resolution, obviously, but can be used to store things like publisher information.
info—Application domain initialization information. This must include, at minimum, an ApplicationBase, representing the store where partial trust assemblies reside.
grantSet—The permission grant set of all loaded assemblies in this domain, except for those on the full trust list or in the Global Assembly Cache.
fullTrustAssemblies—A list of StrongNames of assemblies that are granted full trust (exempt from partial trust).

Once the domain is created, you can call AppDomain.CreateInstanceAndUnwrap on a MarshalByRefObject in your partial trust assembly and then call into its entry point method to kick it off, as shown in Figure 2.

Figure 2 Sandbox with Partial Trust Code Running Inside

PermissionSet permset = new PermissionSet(PermissionState.None);
ps.AddPermission(new SecurityPermission(
   SecurityPermissionFlag.Execution));
AppDomainSetup ptInfo = new AppDomainSetup();
ptInfo.ApplicationBase = ptAssemblyStore;
 
AppDomain sandboxedDomain = AppDomain.CreateDomain(
   "Sandbox",
   AppDomain.CurrentDomain.Evidence,
   ptInfo,
   permset);
 
// assume HarnessType is in the GAC and a MarshalByRef object

HarnessType ht = sandboxedDomain.CreateInstanceAndUnwrap(
   typeof(HarnessType).Assembly.FullName,
   typeof(HarnessType).FullName)
   as HarnessType;
 
ht.LoadPTEntryPoint();

That’s it! With several lines of code, we now have a sandbox with partial trust code running in it.

This CreateDomain API was actually added in .NET Framework 2.0, so it’s not new. However, it’s worth mentioning as it’s now the only truly supported way to sandbox code. As you can see, the permission set is passed directly, so no evidence has to be evaluated in loading assemblies into this domain; you know exactly what each loaded assembly is going to get. Furthermore, you’re using a real isolation boundary to contain partial trust code, which is extremely helpful in making security assumptions. With the simple sandboxing CreateDomain API, sandboxes become more obvious, consistent and secure—all things that help make dealing with untrusted code easier.

Enforcement

At this point, we have an appropriate permission grant set for our partial trust assembly and have loaded the assembly into a proper sandbox. Great! However, what if we actually want to expose some elevated functionality to partially trusted code? For example, I may not want to give full file system access to an Internet application, but I don’t mind if it reads and write from a known temporary folder.

Those of you who read last year’s column on Silverlight security (msdn.microsoft.com/magazine/cc765416.aspx) know exactly how this issue is addressed in that platform—through the Security Transparency model that neatly divides code into three buckets. I’m happy to say that Silverlight’s advancement of the model is now in effect on .NET Framework 4. This means that the benefits of the simpler model enjoyed by the Silverlight platform libraries are now available to non-Microsoft developers of partial trust libraries. Before I go into that and other improvements in the enforcement space, though, I’ll discuss our primary enforcement mechanisms from before.

Enforcement in the Past

I mentioned last year that Security Transparency was actually introduced in .NET Framework 2.0, but served primarily as an audit mechanism rather than an enforcement one (the new Security Transparency model is both). In the older model, or Level 1 Security Transparency, violations did not manifest themselves as hard failures—many of them (like p/invoking into native code) resulted in permission demands. If your transparent assembly happened to have UnmanagedCode in its grant set, it could still go ahead and do what it was doing (violating the Transparency rules in the process). Furthermore, Transparency checks stopped at the assembly boundary, further reducing its enforcement effectiveness.

True enforcement in the .NET Framework 2.0 came in the form of LinkDemands— JIT time checks that checked if the grant set of the calling assembly contained the specified permission. That was all well and good, but this model essentially required library developers to use two different mechanisms for audit and enforcement, which is redundant. The Silverlight model, which consolidated and simplified these two concepts, was a natural progression from this state and became what is now Level 2 Security Transparency.

Level 2 Security Transparency

Level 2 Security Transparency is an enforcement mechanism that separates code that is safe to execute in low-trust environments and code that isn’t. In a nutshell, it draws a barrier between code that can do security-sensitive things (Critical), like file operations, and code that can’t (Transparent).

The Security Transparency model separates code into three buckets: Transparent, Safe Critical and Critical.. The following diagram, Figure 3, describes these buckets. (Note: Green arrows represent calls that are allowed; red arrows represent those that aren’t. Self-loops are valid as well, but not shown.)

Figure 3 Security Transparency Model

For typical desktop applications, the Level 2 Transparency model has no noticeable effect—code that does not have any security annotations and is not sandboxed is assumed to be Critical, so it is unrestricted. However, since it is Critical, it is off-limits to partial trust callers. Therefore, developers who don’t have partial trust scenarios won’t have to worry about exposing anything to partial trust.

For sandboxed applications, the opposite is true—any assembly loaded into a sandboxed application domain is assumed to be completely Transparent (even if it has annotations specifying otherwise). This ensures that partial trust code cannot attempt to elevate via asserting for permissions or calling into native code (a Full Trust equivalent action).

Libraries exposed to partial trust callers, unlike desktop or sandboxed apps, must be keenly aware of their security requirements and have much more flexibility over their abilities and what they expose. A typical partial trust-callable library should be primarily Transparent and Critical code with a minimal set of Safe Critical APIs. Critical code, while unrestricted, is known to be inaccessible from partial trust code. Transparent code is callable from partial trust code but is safe. Safe Critical code is extremely dangerous, as it provides elevated functionality, and utmost care must be taken to make sure its caller is validated before transitioning over to Critical code.

The Security Transparency attributes and their behaviors are listed and described in Figure 4. Keep in mind that the highest-scoped attribute applies for all introduced APIs under it, regardless of whether those APIs have their own annotations. AllowPartiallyTrustedCallers is different in that it defers to and honors lower-level attributes. (Note: This table describes the attributes and their behavior when applied at the assembly, type or member level. The attributes apply only to introduced APIs, which means subclasses and overrides are subject to the inheritance rules and may be at different Transparency levels.)

Figure 4 Security Transparency Attributes and Their Behaviors

Those of you who remember last October’s article will probably notice that the attributes work, more or less, the same way they do in Silverlight. You might also remember that there were specific inheritance rules associated with the different types of code. Those are also in effect in the desktop. For more details on the inheritance rules and other aspects of Level 2 Transparency, take a look at last year’s article, “Security in Silverlight 2” (msdn.microsoft.com/magazine/cc765416.aspx).

Conditional AllowPartiallyTrustedCallers

The AllowPartiallyTrustedCallers attribute (APTCA) indicates that an assembly is a library that may expose security-sensitive functionality to partial trust. APTCA library assemblies are often written in conjunction with hosts, since the hosts typically want to expose specific functionality to their hosting environments. One major example is ASP.NET, which exposes the System.Web namespace to its hosted code, which may be at various trust levels.

However, putting APTCA on an assembly means it’s available to partial trust in any host that decides to load it, which can be a liability if the assembly author doesn’t know how that assembly will behave in different hosts. Therefore, host developers sometimes want their libraries to be available to partial trust only when loaded in their own domains. ASP.NET does exactly this, and in earlier versions has had to use LinkDemands for special permissions on their APIs. While this works, it causes everyone building on top of them to have to satisfy that LinkDemand, preventing those up-stack assemblies from being transparent.

To solve this, we introduced the Conditional APTCA feature,which allows libraries to expose APIs to partial trust callers only in an enabling host (via a list).

The specific roles of the host and library are:

The library simply qualifies the AllowPartiallyTrustedCallers attribute with a parameter, the PartialTrustVisibilityLevel enum. For example:
[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel= PartialTrustVisibilityLevel.NotVisibleByDefault)]
This attribute basically says that the library is not callable from partial trust unless the host has it on its allow-list, mentioned below. A value of VisibleToAllHosts would make the library callable from partial trust in all hosts.
The host specifies partial trust visible assemblies, per application domain, via an allow list. This list is typically populated via a configuration file supplied to the host. An important thing to keep in mind is that unconditional APTCA assemblies, like the basic framework libraries, do not have to be added to this list.(Also important to keep in mind is that if you’re enabling a Conditional APTCA assembly, you should enable its transitive closure of dependent Conditional APTCA assemblies as well. Otherwise, you might end up with odd behavior, as your original assembly tries to call APIs that it assumes are accessible but really aren’t.)

Easier to Secure

Much has happened in the security model for the .NET Framework 4. CAS policy has been disabled by default, leaving all security policy decisions up to the host and granting unhosted managed exes behavioral parity with native exes. Disabling CAS policy has also disabled heterogeneous application domains, finally making the efficient simple-sandboxing CreateDomain overload the primary supported sandboxing mechanism for partial trust assemblies. Silverlight’s improvements to the Security Transparency model, described last October, have also come to the desktop, providing partial trust library developers with the same efficiency and cleanliness benefits that were provided to the Silverlight platform.

We’ve crafted these changes in such a way that most applications will continue to work as they have before, but the host and library developers out there will find a simpler model to work with—one that is more deterministic, simpler to use and, therefore, easier to secure.

Andrew Dai is a program manager on the CLR security team. For more, in-depth information on how to use the features mentioned in this article, please visit the CLR team blog (blogs.msdn.com/clrteam) and Shawn Farkas’ .NET security blog (blogs.msdn.com/shawnfa).

CLR INSIDE OUT

Exploración del modelo de seguridad de .NET Framework 4

Andrew Dai

.NET Framework 4 introduce muchas actualizaciones al modelo de seguridad .NET que facilitan en gran medida hospedar, asegurar y proporcionar servicios a un código de confianza parcial. Nos hemos mejorado el sistema de directiva de seguridad de acceso a código (CAS) complicado, que era incluso más difícil obtener derecho pero difícil de utilizar y eficaz. Hemos también mejorado sobre el modelo de transparencia de seguridad, poniendo gran parte de las mejoras de Silverlight (que hablado pasado octubre: MSDN.Microsoft.com/magazine/cc765416.aspx) en el cumplimiento de seguridad para el marco de trabajo del escritorio. Por último, nos hemos introducido algunas características nuevas que asigne a los desarrolladores de biblioteca y de host más flexibilidad sobre donde se exponen sus servicios. Con estos cambios, el 4 de .NET Framework se consigue excepcional un modelo de seguridad más sencilla y mejorada que facilita la tarea para hosts y bibliotecas para código de recinto de seguridad y las bibliotecas para exponer de forma segura servicios.

Un fondo en .NET Framework Security

Antes de profundizar en cualquier característica particular, resulta útil para tener fondo un poco acerca de cómo funciona la seguridad en .NET Framework. Código de confianza parcial está restringido por los permisos que tiene y distintas API requerirá permisos diferentes para llamarlo correctamente. El objetivo de CAS es asegurarse de que el código no confiable se ejecuta con permisos apropiados y no puede hacer nada más allá de sus permisos sin autorización.

Podemos pensar del modelo de seguridad de .NET como que comprende tres partes. Se han realizado mejoras específicas en cada área y el resto de este artículo está organizado conforme a estas tres secciones fundamentales:

Directiva: Directiva de seguridad determina qué permisos conceder a un ensamblado determinado que no son de confianza o la aplicación. Código administrado tiene objetos de evidencia asociadas, que puede describir donde se carga el código desde, quién lo publicó y así sucesivamente. Evidencia se puede utilizar para determinar qué permisos son adecuados; el resultado se denomina un conjunto de concesión de permisos. .NET Framework ha utilizado directiva CAS tradicionalmente como un mecanismo de todo el equipo para controlar esto. Como se mencionó antes, directiva CAS ha sido mejorado en favor de dar más flexibilidad de hosts a través de su propia directiva de seguridad y el código unhosted paridad con código nativo.
Bloqueo sandboxing — Recintos de seguridad es el proceso real de restringir ensamblados o aplicaciones a un determinado permiso conceden conjunto. La forma preferida de recinto de seguridad es crear un dominio de aplicación de recinto de seguridad que contiene una concesión de permiso establecido para los ensamblados cargados y una lista de exenciones para los ensamblados de biblioteca específica (éstos reciben plena confianza). Con obsoletion de directiva de CAS, código de confianza parcial siempre obtiene recinto de este modo en .NET Framework 4.
Cumplimiento — Cumplimiento hace referencia al mecanismo que mantiene el código no confiable restringido a su recinto de seguridad. Uso correcto de cumplimiento API impide que un ensamblado que no son de confianza desde simplemente llamar a una API en un ensamblado diferente, más confianza y ejercer permisos mayores de ese modo. También permite a los desarrolladores de host y biblioteca exponer acceso controlado, limitado a comportamiento elevado y proporcionar servicios significativos al código de confianza parcial. El modelo de transparencia de seguridad de nivel 2 facilita mucho para ello de forma segura.

El modelo de seguridad de .NET siempre ha sido de particular importancia para los desarrolladores de host y la biblioteca (que vaya a menudo mano en la mano). Ejemplos del modelo de seguridad de .NET son ASP.NET y SQL CLR, qué ambos host código dentro de entornos controlados y restringidos contextos administrado. Cuando un host como éstas desea cargar un ensamblado de confianza parcial, crea un dominio de aplicación sandboxed con el conjunto de concesión de permisos adecuado. A continuación, se carga el ensamblado en este dominio recinto. El host también proporciona la biblioteca API que están totalmente de confianza pero puede llamar desde el código alojado. Las bibliotecas también se cargan en el recinto de seguridad dominio, pero se colocan explícitamente en la lista de exenciones que se ha mencionado anteriormente. Que se basan en mecanismos de exigencia de .NET Framework para garantizar que el acceso a sus capacidades elevados se controla estrechamente.

Para la mayoría de los desarrolladores de aplicación administrada, esto es todo mágica que sucede en el nivel de marco, incluso los desarrolladores escribir código que se va a ejecutar en un recinto de seguridad no es necesario conocer todos los detalles de cómo funciona el modelo de seguridad. El marco de trabajo garantiza recinto del código está limitado a utilizar las API y capacidades que proporciona el host. El modelo de seguridad de .NET y CAS han sido durante mucho tiempo el territorio de los administradores de empresa y los desarrolladores de host y la biblioteca; para ellos, hemos facilitado cosas que nunca.

Directiva

Se ha proporcionado la directiva CAS desde el inicio de ..NET Framework para ofrecer una forma para ajustar con precisión qué considera el tiempo de ejecución de confianza o que no son de confianza a los administradores de equipo y empresa. Mientras la directiva CAS era muy eficaz y permitidos para los controles muy granulares, era extremadamente difícil obtener derecho y se puede dificultar más de Ayuda. Los administradores de equipo podrían bloquear ciertas aplicaciones out of permisos necesarios (descritos en la siguiente sección principal, recinto) y muchas personas se habrá preguntado por qué sus aplicaciones repentinamente dejado de funcionar una vez decidieron ponerlos en un recurso compartido de red. Además, configuración de directiva de CAS no avanzar de una versión del motor en tiempo de ejecución a otro, por lo que tenía la directiva CAS personalizada elaborada que alguien ha configurado en .NET Framework 1.1 que se van a Rehacer manualmente para .NET Framework 2.0.

Directiva de seguridad podría dividirse en dos escenarios: directiva de seguridad para alojado código y una directiva de seguridad para la empresa o equipo. Con respecto a la directiva de equipo, el equipo de seguridad de Common Language Runtime ha decidido que el motor en tiempo de ejecución era el lugar equivocado para regir, como código nativo obviamente no era con sus restricciones. Mientras tiene sentido para los hosts poder determinar qué puede hacer su código alojado, exes unhosted que simplemente se hace clic en o a ejecutar desde la línea de comandos deben se comportan como los equivalentes nativos (sobre todo porque parecen idénticos a los usuarios ejecuten).

Es el lugar correcto para la directiva de seguridad global en el nivel de sistema operativo, donde dicha directiva se aplicaría a nativo y código administrado igualmente. Por tanto, nos estamos anima a los administradores de equipo para observar las soluciones como directivas de restricción de software de Windows y la resolución de directiva de CAS de todo el equipo al deshabilitar de forma predeterminada. El otro escenario, directiva de seguridad para código alojado, sigue siendo muy válido en el mundo del código administrado. Ahora es más fácil rigen, directiva de seguridad de host como que ya no entrar en conflicto con una directiva de equipo arbitrario.

Esto significa para usted

En una, todas unhosted se ejecuta código administrado como de plena confianza de manera predeterminada. Si ejecuta un archivo .exe desde la unidad de disco duro o un recurso compartido de red, la aplicación tendrá todas las capacidades tendría una aplicación nativa que se ejecuta desde el mismo lugar. Sin embargo, es código alojado, estando sujeto a las decisiones de seguridad de los host.(Note that all the ways that code can arrive via the Internet are hosted scenarios—ClickOnce applications, for example—so this does not mean that code running over the Internet is fully trusted.)

Para muchas aplicaciones, estos cambios son principalmente en segundo plano y no tendrá ningún efecto aparente. Los que se ven afectados por el cambio pueden encontrarse con dos problemas. La primera es que determinadas API relacionadas con directiva de CAS están en desuso, muchos relacionadas con cargas de ensamblado (lo que leer en este caso en absoluto). Segundo y que afecta al menos personas (principalmente hosts), será el hecho de que los dominios de aplicación heterogéneos (que se describen en la sección recinto) no están disponibles de forma predeterminada.

Pero no Estoy realizando cualquiera de esto! ¿Qué debo hacer para simplemente que éste funcione?

Quizás ha ejecutado en un mensaje de error o obsoletion parecía algo así:

Este método [explícitamente o implícitamente] utiliza Directiva de CAS, que ha sido obsoletos por .NET Framework. Para habilitar la directiva de CAS por motivos de compatibilidad, utilice el modificador de configuración de NetFx40_LegacySecurityPolicy. Para obtener más información, consulte [vínculo documentación de MSDN].

Por razones de compatibilidad, te proporcionamos un modificador de configuración que permite a un proceso habilitar la resolución de directiva de CAS en él. Puede habilitar la directiva CAS colocando los siguientes en el archivo del proyecto app.config:

<configuration>
   <runtime>
      <!-- enables legacy CAS policy for this process -->
      <NetFx40_LegacySecurityPolicy enabled="true" />
   </runtime>
</configuration>

La siguiente sección describe dónde empezar buscando la migración, si se inicie la excepción desde su propio código. Si no lo es, a continuación, el modificador de configuración es la forma de ir y no debería aplicar la siguiente sección directamente.

API afectadas

API afectadas pueden dividirse en dos grupos: las que explícitamente utiliza Directiva de CAS y los que está utilizando de forma implícita. Los usos explícitos son obvios, que tienden a residen en la clase System.Security.Policy.SecurityManager y aspecto SecurityManager.ResolvePolicy. Estas API llamar directamente o modifiquen la configuración del equipo CAS directiva y han todos quedado en desuso.

Usos implícitos son menos obvios, éstas tienden a ser cargas de ensamblado o creaciones de dominio de aplicación que toman la evidencia. Directiva de CAS se resuelve en esta evidencia, y el ensamblado se carga con el conjunto de concesión de permiso resultante. Puesto que la directiva CAS está desactivada de forma predeterminada, no tiene sentido para intentar resolver en esta evidencia. Un ejemplo de tal una API es Assembly.Load (AssemblyName assemblyRef, assemblySecurity Evidence).

Hay un par de por qué se llamaría una API de esta razones:

Bloqueo sandboxing: Perhaps sabe que una llamada a esa sobrecarga Assembly.Load con evidencia de zona de Internet tendrá como resultado de que el conjunto de permisos con nombre de ensamblado que se está cargando con Internet (a menos que, es decir, un administrador cambió esa asignación evidencia para este usuario o equipo particular!).
Otros parámetros en la sobrecarga, Tal vez simplemente deseaba llegar a un parámetro específico que existía sólo en esta sobrecarga. En este caso, se podría ha simplemente pasar null o .Evidence de Assembly.GetExecutingAssembly () para el parámetro evidence.

Si está intentando crear un recinto de seguridad, la sección recinto describe cómo crear un dominio de aplicación sandboxed restringido a Internet conjunto de permisos con nombre El ensamblado, a continuación, se puede cargar en ese dominio y se garantiza que tiene los permisos que pretende (es decir, no asunto para los whims de un administrador).

En el segundo escenario, hemos agregado sobrecargas a cada una de estas API que exponen todos los parámetros necesarios pero no exponen un parámetro evidence. Migración es una simple cuestión de cortar el argumento evidencias para las llamadas out. (Observe que todavía pasando evidencia null en una API obsoleta funciona también, como no dar como resultado en la evaluación de directiva de CAS).

Es un elemento adicional a tener en cuenta que si está realizando una carga de ensamblados desde una ubicación remota (es decir, Assembly.LoadFrom(“http://...”)), inicialmente obtendrá un FileLoadException a menos que se establezca el siguiente modificador de configuración. Esto se hizo porque esta llamada sería ha recinto el ensamblado en el pasado. Con la directiva de CAS ha desaparecido, es de plena confianza!

<configuration>
   <runtime>
      <!-- WARNING: will load assemblies from remote locations as fully
         trusted! -->
      <loadFromRemoteSources enabled="true" />
   </runtime>
</configuration>

Otra forma de hacerlo, sin activar este modificador para todo el proceso es utilizar la nueva API de Assembly.UnsafeLoadFrom, que actúa como LoadFrom con el modificador configurado. Esto es útil si sólo desea habilitar remotos cargas en determinados lugares o no lo tienes la aplicación principal.

Con la directiva CAS de todo el equipo de la imagen, se deja todos examen de evidencia de ensamblado y decisiones relacionadas con conjuntos de permisos adecuados al hosts de código administrado. Sin un sistema complicado en la parte superior interfiriendo con sus decisiones de seguridad (aparte de cualquier directiva de seguridad OS), un host es libre de asignar sus propios permisos. Ahora es el momento de asignar dichos permisos a los ensamblados de confianza parcial.

Recintos de seguridad

A través directiva de seguridad del host de una, podemos determinar el conjunto de concesión de permisos correcto para dar a un ensamblado de confianza parcial. Ahora necesitamos un modo sencillo y eficaz para cargar dicho ensamblado en un entorno que está restringido a ese conjunto concreto de la concesión. Recinto de seguridad, particularmente mediante la sobrecarga de CreateDomain grupales simple, no sólo eso.

Recinto de seguridad en el pasado

Con el antiguo modelo de directiva de CAS, era posible crear un dominio de aplicación heterogéneos, donde cada ensamblado en el dominio tenía su propio permiso establecido. Dos o más ensamblados en niveles diferentes de confianza parcial que se está cargados en el mismo dominio que realiza la carga el ensamblado de plena confianza puede provocar una carga de ensamblados con evidencia de zona de Internet. Además, el dominio de aplicación podría tener su propia evidencia, dándole su propio conjunto de permisos.

Hay varios problemas con este modelo:

El conjunto de permisos concedidos a un ensamblado depende de directiva de CAS, tal como se intersecan varios niveles de directiva para calcular el conjunto de permisos final. Por tanto, es posible acabar con menos permisos lo esperado.
Similar al punto anterior, evaluación de evidencia en un ensamblado se realiza mediante la directiva de CAS, que podría ser diferente a través de equipos, usuarios e incluso versiones del motor de tiempo de ejecución (directiva de CAS configuración no avanzar con nuevas versiones del motor en tiempo de ejecución). Por tanto, no siempre evidente qué conjunto de concesión de permisos estaba obteniendo un ensamblado.
Normalmente, los ensamblados de confianza parcial no se examinan para seguridad refuerzo, por lo que ensamblados “ confianza intermedio ” vulnerables a los ensamblados “ más bajo de confianza ”. Los ensamblados son libremente y fácilmente pueden llamar a otro, por lo que tener muchos de ellos con distintas capacidades se convierte en problemática desde una perspectiva de seguridad. ¿Alguien puede seguro de que cada combinación de llamadas desde ensamblados en distintos niveles de confianza es segura? ¿Es absolutamente seguro almacenar en caché la información desde una capa de confianza medio?

Debido a estos problemas de, se introdujo el concepto de un dominio de aplicación homogénea, que contiene sólo dos conjuntos de concesión de permiso (confianza parcial y plena confianza) y es muy sencilla de crear y razón acerca. Dominios homogéneos y cómo crearlos, se describen más adelante en esta sección.

Otro mecanismo popular para recintos de seguridad era el uso de PermitOnly y Deny, que son pila recorrer modificadores ese permisos permitido específico de lista (y nada más) y no permitir permisos específicos, respectivamente. Parecía útil diga, “ sólo quiero los llamadores con permisos x e y para poder llamar a esta API, ” o “ como una API, desea denegar permiso a todos los llamadores de Mis. ” Sin embargo, estos modificadores hizo el cambio no realmente el conjunto de concesión de permisos de un ensamblado determinado, lo que significaba que podría ser garantizadas inmediatamente porque todo lo hacían fue intersección demandas. Se muestra un ejemplo de esto en acción en de figura 1.

Figura 1 de llamar pila Representing denegar un intento de recinto con

Sin el rojo Assert, Deny de aciertos de la demanda y se termina el recorrido de pila. Cuando la aserción roja está activa, sin embargo, la denegación no se nunca visita, como untrusted ha garantizada la demanda ausente. (Notas: Pila de llamadas es decreciente. API no representan API reales en el marco de trabajo.) Por este motivo, denegar está en desuso en la 4 .NET Framework, como utilizarlo es siempre un agujero de seguridad (PermitOnly es todavía alrededor porque se puede utilizar de forma legítima en algunos casos de esquina, pero generalmente se recomienda no). Tenga en cuenta que puede ser reactiva mediante el modificador NetFx40_LegacySecurityPolicy, mencionado en la sección de directiva anterior.

Creación de recintos de seguridad hoy

Para .NET Framework, la unidad de aislamiento que utilizamos es el dominio de aplicación. Cada dominio de aplicación de confianza parcial tiene un conjunto de concesión de permiso único obtienen todos los ensamblados cargados, excepto el de los enumerados en la lista de exenciones de plena confianza específicamente o cargado desde la caché de ensamblados global. Creación de este dominio es muy sencilla, ..NET Framework proporciona un recinto de seguridad simple API que tome en todo lo necesita para crear el dominio:

AppDomain.CreateDomain( string friendlyName,
 
                        Evidence securityInfo,
                        
                        AppDomainSetup info,
                        
                        PermissionSet grantSet,
                        
                        params StrongName[] fullTrustAssemblies);

Donde los parámetros son:

friendlyName; El nombre descriptivo del dominio de aplicación.
securityInfo — Evidencia asociada con el dominio de aplicación. Esto no se utiliza para la resolución de la directiva de CAS, obviamente, pero se puede utilizar para almacenar elementos como información del editor.
Info, Información de inicialización del dominio de aplicación. Esto debe incluir, como mínimo, una instancia de ApplicationBase, que representa el almacén donde residen los ensamblados de confianza parcial.
grantSet; El permiso conceder el conjunto de ensamblados cargados todo en este dominio, excepto en la lista de plena confianza o en la caché de ensamblados global.
fullTrustAssemblies — Una lista de StrongNames de ensamblados que se otorgan plena confianza (exentos de confianza parcial).

Una vez creado el dominio, puede llamar a AppDomain.CreateInstanceAndUnwrap en un MarshalByRefObject en su ensamblado de confianza parcial y, a continuación, llamar a su método de punto de entrada que activarse desactivado, como se muestra en de figura 2.

Figura 2 de recinto con código de confianza parcial Running Inside

PermissionSet permset = new PermissionSet(PermissionState.None);
ps.AddPermission(new SecurityPermission(
   SecurityPermissionFlag.Execution));
AppDomainSetup ptInfo = new AppDomainSetup();
ptInfo.ApplicationBase = ptAssemblyStore;
 
AppDomain sandboxedDomain = AppDomain.CreateDomain(
   "Sandbox",
   AppDomain.CurrentDomain.Evidence,
   ptInfo,
   permset);
 
// assume HarnessType is in the GAC and a MarshalByRef object

HarnessType ht = sandboxedDomain.CreateInstanceAndUnwrap(
   typeof(HarnessType).Assembly.FullName,
   typeof(HarnessType).FullName)
   as HarnessType;
 
ht.LoadPTEntryPoint();

Eso es todo! Con varias líneas de código, ahora tenemos un recinto de seguridad con ejecutar el código de confianza parcial.

Esta API CreateDomain se agregó realmente en .NET Framework 2.0, por lo que no es nuevo. Sin embargo, merece la pena mencionar como ahora es la única manera realmente compatible para crear un recinto de seguridad para el código. Como puede ver, el conjunto de permisos se pasa directamente, por lo que no tiene ninguna evidencia que se va a evaluar en cargar ensamblados en este dominio; sabe exactamente qué cada ensamblado cargado se va a obtener. Además, utiliza un límite de aislamiento real para contener código de confianza parcial, que es extremadamente útil para realizar suposiciones de seguridad. Con el recinto de seguridad simple CreateDomain API, convertirse en recintos más obvios, coherente y segura, todo lo que ayudan a que no confiable que tratar con código más fácil.

Cumplimiento

En este punto, tenemos un permiso adecuado conceder conjunto para nuestro ensamblado de confianza parcial y haya cargado el ensamblado en un recinto de seguridad adecuado. ¡Genial! Sin embargo, ¿qué ocurre si realmente deseamos exponer algunos elevados funcionalidad al código de confianza parcial? Por ejemplo, puede no deseo asignar acceso de sistema de archivo completo a una aplicación de Internet, pero yo no le importa si lee y escribir desde una carpeta temporal conocida.

Aquellos que lea la columna del año pasado en la seguridad de Silverlight (msdn.microsoft.com/magazine/cc765416.aspx de ) saben exactamente cómo se señala este problema en esa plataforma — a través de la transparencia de seguridad modelar es claramente código divide en tres depósitos. Soy feliz diga que avance del Silverlight del modelo ahora está en vigor en .NET Framework 4. Esto significa que las ventajas del modelo más sencillo disfrutado por las bibliotecas de la plataforma Silverlight ahora están disponibles para los desarrolladores que no sean de Microsoft de bibliotecas de confianza parcial. No obstante, antes de que entraré en y otras mejoras en el espacio de cumplimiento, Hablaré sobre nuestros mecanismos de exigencia principal de antes.

Cumplimiento en el pasado

Mencioné el último año que transparencia de seguridad era realmente introducida en .NET Framework 2.0, pero sirve principalmente como un mecanismo de auditoría en lugar de un cumplimiento uno (el nuevo modelo de transparencia de seguridad es ambas). En el modelo anterior, o transparencia de seguridad de nivel 1, infracciones no manifiestan errores como disco duros, muchos de ellos (como p/invocar a código nativo) resultó en peticiones de permiso. Si su ensamblado transparente ocurrido tener UnmanagedCode en su conjunto de permisos concedidos, aún podría seguir adelante y hacer lo que hacía (infringir las reglas de transparencia en el proceso). Además, comprobaciones de transparencia detenidos en el límite del ensamblado, aún más lo que reduce su efectividad de cumplimiento.

True cumplimiento en .NET Framework 2.0 viene en forma de LinkDemands, comprobaciones en tiempo de JIT que comprueba si el conjunto concedido del ensamblado que realiza llamada contenía el permiso especificado. Que era todos bien y buena, pero este modelo requiere esencialmente la biblioteca a los desarrolladores utilizar dos mecanismos diferentes para auditoría y cumplimiento, que es redundante. El modelo de Silverlight, que consolidado y simplificado de estos dos conceptos, era un avance natural desde este estado y se convirtió en ¿qué es ahora de transparencia de seguridad de nivel 2.

Transparencia de seguridad de nivel 2

Transparencia de seguridad de nivel 2 es un mecanismo de exigencia de que separa el código que es seguro ejecutar en entornos de confianza baja y código que no. En pocas palabras, dibuja una barrera entre el código que puede hacer cosas de seguridad (crítica), como operaciones de archivo y el código que no se puede (transparente).

El modelo de transparencia de seguridad separa el código en tres depósitos: Transparente, seguros crítica y crítico El diagrama siguiente, de figura 3, describe estos depósitos. (Nota: Flechas verdes representan las llamadas que se permiten; flechas rojas representan aquellos que no están. Self-Loops son válidos, pero no se muestran.)

Figura 3 de modelo de transparencia de seguridad

Para las aplicaciones de escritorio típicas, el modelo de transparencia de nivel 2 no tiene ningún efecto apreciable: código que no tiene las anotaciones de seguridad y no es recinto se supone que es crítico, por lo que es no restringido. Sin embargo, puesto que es crítica, es off-limits para llamadores de confianza parcial. Por tanto, los desarrolladores que no dispongan de escenarios de confianza parcial no tienen que preocuparse exponer nada para confianza parcial.

Para las aplicaciones de recinto, lo contrario es true, cualquier ensamblado cargado en un dominio de aplicación sandboxed se supone que es completamente transparente (incluso si tiene las anotaciones que especifica lo contrario). Esto garantiza que el código de confianza parcial no puede intentar elevar a través de la aserción de permisos o llamar a código nativo (una acción equivalente Full Trust).

Bibliotecas expuestas a llamadores de confianza parcial, a diferencia de las aplicaciones de escritorio o recinto, deben tener muy en cuenta sus requisitos de seguridad y tener mucha más flexibilidad a través de sus capacidades y que exponen. Una biblioteca de trust-callable parcial típico debe ser principalmente código Transparent y crítico con un conjunto mínimo de API críticas seguros. El código crítico, mientras no restringido, se sabe ser inaccesibles desde el código de confianza parcial. El código transparente se puede llamar desde código de confianza parcial, pero es seguro. Seguro código crítico es extremadamente peligroso, ya que proporciona funcionalidad elevado, y máxima debe tener cuidado para asegurarse de que su llamador se valida antes de realizar la transición a través de código crítico.

Los atributos de transparencia de seguridad y sus comportamientos se enumeran y describen en de figura 4. Tenga en cuenta que se aplica el atributo de ámbito más alto para todas las API introducidas debajo, independientemente de si tienen sus propias anotaciones o esas API. AllowPartiallyTrustedCallers es diferente en que se pospone a y respeta los atributos de nivel inferior. (Nota: Esta tabla describe los atributos y su comportamiento cuando se aplica en el nivel de ensamblado, tipo o miembro. Los atributos se aplican sólo a las API introducidas, lo que significa subclases y reemplazos están sujetos a las reglas de herencia y pueden estar en diferentes niveles de transparencia.)

Figura 4 de atributos de transparencia de seguridad y sus comportamientos

Aquellos que recuerde artículo del pasado octubre probablemente observará que los atributos funcionan más o menos, del mismo modo que lo hacen en Silverlight. Quizá recuerde también que se produjeron herencia específica reglas asociadas con los distintos tipos de código. También son en efecto en el escritorio. Para obtener más detalles sobre las reglas de herencia y otros aspectos de transparencia de nivel 2, eche un vistazo al artículo del año pasado, “ seguridad en Silverlight 2 ” (msdn.microsoft.com/magazine/cc765416.aspx de ).

AllowPartiallyTrustedCallers condicional

El atributo AllowPartiallyTrustedCallers (APTCA) indica que un ensamblado es una biblioteca que puede exponer funcionalidad security-sensitive para confianza parcial. Los ensamblados de biblioteca APTCA se escriben con frecuencia junto con los hosts, ya que los hosts normalmente desean exponer funcionalidad específica para sus entornos de alojamiento. Un ejemplo principal es ASP.NET, que expone el espacio de nombres System.Web a su código alojado, que puede estar en varios niveles de confianza.

Sin embargo, colocar APTCA en un medio de ensamblado está disponible para confianza parcial en cualquier host que decide para cargarlo, que puede ser un pasivo si el autor del ensamblado no sabe cómo se comportará ese ensamblado en distintos hosts. Por tanto, los desarrolladores de host a veces desean sus bibliotecas estén disponibles para confianza parcial sólo al cargar en sus propios dominios. ASP.NET hace exactamente esto y en versiones anteriores ha tenido que utilizar LinkDemands para permisos especiales en sus API. Aunque esto funciona, hace que todos los usuarios generar en la parte superior de que tengan que satisfacer esa LinkDemand, impidiendo que esos ensamblados de la pila de arriba de ser transparente.

Para resolver este problema, presentamos la característica de APTCA condicional, que permite bibliotecas exponen API a los llamadores de confianza parcial sólo en un host habilitación (a través de una lista).

Las funciones específicas del host y biblioteca son:

La biblioteca califica simplemente el atributo AllowPartiallyTrustedCallers con un parámetro, la enumeración PartialTrustVisibilityLevel. Por ejemplo:
[assembly: AllowPartiallyTrustedCallers(PartialTrustVisibilityLevel= PartialTrustVisibilityLevel.NotVisibleByDefault)]
Este atributo básicamente indica que la biblioteca no puede llamar desde una confianza parcial a menos que el host lo tiene en su lista Permitir, mencionadas a continuación. Un valor de VisibleToAllHosts haría que la biblioteca que se puede llamar desde en todos los hosts de confianza parcial.
El host especifica visible ensamblados de confianza parcial, por dominio de aplicación, a través de una lista de permitidos. Esta lista normalmente se rellena mediante un archivo de configuración proporcionado para el host. Una cosa importante a tener en cuenta es que los ensamblados APTCA incondicionales, como las bibliotecas de marco de trabajo básico, no es necesario que se va a agregar a esta lista. (también es importante tener en cuenta es que si está habilitando un ensamblado APTCA condicional, debe habilitar su cierre transitivo de los ensamblados dependientes APTCA condicional también. De lo contrario, podría terminará con un comportamiento extraño, como el ensamblado original intenta llamar a API que se supone que son accesibles, pero no están realmente.)

Más fácil de seguros

Gran parte ha sucedido en el modelo de seguridad para el 4 de .NET Framework. Directiva de CAS se ha deshabilitado de forma predeterminada, dejando toda la seguridad de las decisiones de directiva up to el host y concesión a unhosted exes administrados comportamiento paridad con exes nativos. Deshabilitar la directiva CAS también ha deshabilitado los dominios de aplicación heterogéneos, que finalmente hace el bloqueo sandboxing-simple eficaz CreateDomain sobrecargar el mecanismo principal recintos de seguridad compatibles para los ensamblados de confianza parcial. Mejoras de Silverlight para el modelo de transparencia de seguridad descrito pasado octubre, también proceder al escritorio, ofreciendo a los desarrolladores de biblioteca de confianza parcial con la misma eficiencia y ventajas de limpieza que se facilitaron a la plataforma Silverlight.

Nos hemos diseñado estos cambios en dicha forma que la mayoría de las aplicaciones continuarán funcionando como tienen antes, pero los desarrolladores de host y biblioteca ahí encontrará un modelo más sencillo para trabajar con — uno que sea más determinista, más fácil utilizar y, por tanto, más fácil proteger.

Andrew Dai es un administrador de programas en el equipo de seguridad CLR. Para obtener más información detallada acerca de cómo utilizar las características mencionadas en este artículo, visite el blog del equipo de CLR (blogs.msdn.com/clrteamde ) y el blog de seguridad de .NET de Shawn Farkas ’ (blogs.msdn.com/shawnfa de ).

MSDN Magazine Blog

MSDN Magazine May Issue Preview
Tomorrow afternoon the May issue of MSDN Magazine will go live on our Web site. Here’s what you can look forward to in the upcoming issue. Craig Shoe... More...
martes, abr. 30

Check Out the April Issue of MSDN Magazine
The April issue of MSDN Magazine is live. This month’s issue leads off with Thomas Petchel’s feature, “A Tour of C++/CX,” which explores the C++/CX la... More...
jueves, abr. 4

More MSDN Magazine Blog entries >

Current Issue

Browse All MSDN Magazines

Subscribe to the MSDN Flash newsletter Subscribe to MSDN Flash newsletter

Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.