.NET Framework 4 Security-Transparent Code Security involves three interacting pieces: sandboxing, permissions, and enforcement. Sandboxing refers to the practice of creating isolated domains where some code is treated as fully trusted and other code is restricted to the permissions in the grant set for the sandbox. The application code that runs within the grant set of the sandbox is considered to be transparent; that is, it cannot perform any operations that can affect security. The grant set for the sandbox is determined by evidence. Evidence identifies what specific permissions are required by sandboxes, and what kinds of sandboxes can be created. Enforcement refers to allowing transparent code to execute only within its grant set. .gif) Important |
|---|
Security policy was a key element in previous versions of the .NET Framework. Starting with the .NET Framework version 4, security policy is obsolete. The elimination of security policy is separate from security transparency. For information about the effects of this change and mitigation advice, see Code Access Security Policy Compatibility and Migration. |
This topic describes the transparency model in more detail. It contains the following sections:
Purpose of the Transparency Model
Transparency is an enforcement mechanism that separates code that runs as part of the application from code that runs as part of the infrastructure. Transparency draws a barrier between code that can do privileged things (critical code), such as calling native code, and code that cannot (transparent code). Transparent code can execute commands within the bounds of the permission set it is operating in, but cannot execute, derive from, or contain critical code. The primary goal of transparency enforcement is to provide a simple, effective mechanism for isolating different groups of code based on privilege. Within the context of the sandboxing model, these privilege groups are either fully trusted (that is, not restricted) or partially trusted (that is, restricted to the permission set granted to the sandbox). | Important |
|---|
The transparency model transcends code access security. Transparency is enforced by the just-in-time compiler and remains in effect regardless of the grant set for an assembly, including full trust. |
Transparency was introduced in the .NET Framework version 2.0 to simplify the security model, and to make it easier to write and deploy secure libraries and applications. Transparent code is also used in Microsoft Silverlight, to simplify the development of partially trusted applications. .gif) Note |
|---|
When you develop a partially trusted application, you have to be aware of the permission requirements for your target hosts. You can develop an application that uses resources that are not allowed by some hosts. This application will compile without error, but will fail when it is loaded into the hosted environment. If you have developed your application using Visual Studio, you can enable debugging in partial trust or in a restricted permission set from the development environment. For more information, see How to: Debug a ClickOnce Application with Restricted Permissions. The Calculate Permissions feature provided for ClickOnce applications is also available for any partially trusted application. |
Back to top
Specifying the Transparency Level
The assembly-level SecurityRulesAttribute attribute explicitly selects the SecurityRuleSet rules that the assembly will follow. The rules are organized under a numeric level system, where higher levels mean tighter enforcement of security rules. The levels are as follows: The primary difference between the two transparency levels is that level 1 does not enforce transparency rules for calls from outside the assembly and is intended only for compatibility. | Important |
|---|
You should specify level 1 transparency for compatibility only; that is, specify level 1 only for code that was developed with the .NET Framework 3.5 or earlier that uses the AllowPartiallyTrustedCallersAttribute attribute or does not use the transparency model. For example, use level 1 transparency for .NET Framework 2.0 assemblies that allow calls from partially trusted callers (APTCA). For code that is developed for the .NET Framework 4, always use level 2 transparency. |
Level 2 TransparencyLevel 2 transparency was introduced in the .NET Framework version 4. The three tenets of this model are transparent code, security-safe-critical code, and security-critical code. Transparent code, regardless of the permissions it is granted (including full trust), can call only other transparent code or security-safe-critical code. If the code is partially trusted, it can only perform actions that are allowed by the domain’s permission set. Transparent code cannot do the following: Perform an Assert operation or elevation of privilege. Contain unsafe or unverifiable code. Directly call critical code. Call native code or code that has the SuppressUnmanagedCodeSecurityAttribute attribute. Call a member that is protected by a LinkDemand. Inherit from critical types.
In addition, transparent methods cannot override critical virtual methods or implement critical interface methods. Security-safe-critical code is fully trusted but is callable by transparent code. It exposes a limited surface area of full-trust code. Correctness and security verifications happen in safe-critical code. Security-critical code can call any code and is fully trusted, but it cannot be called by transparent code.
Level 1 TransparencyThe level 1 transparency model was introduced in the .NET Framework version 2.0 to enable developers to reduce the amount of code that is subject to a security audit. Although level 1 transparency was publicly available in version 2.0, it was primarily used only within Microsoft for security auditing purposes. Through annotations, developers are able to declare which types and members can perform security elevations and other trusted actions (security-critical) and which cannot (security-transparent). Code that is identified as transparent does not require a high degree of security auditing. Level 1 transparency states that the transparency enforcement is limited to within the assembly. In other words, any public types or members that are identified as security-critical are security-critical only within the assembly. If you want to enforce security for those types and members when they are called from outside the assembly, you must use link demands for full trust. If you do not, publicly visible security-critical types and members are treated as security-safe-critical and can be called by partially trusted code outside the assembly. The level 1 transparency model has the following limitations: Security-critical types and members that are public are accessible from security-transparent code. The transparency annotations are enforced only within an assembly. Security-critical types and members must use link demands to enforce security for calls from outside the assembly. Inheritance rules are not enforced. The potential exists for transparent code to do harmful things when run in full trust.
Back to top
Transparency Enforcement
Transparency rules are not enforced until transparency is calculated. At that time, an InvalidOperationException is thrown if a transparency rule is violated. The time that transparency is calculated depends on multiple factors and cannot be predicted. It is calculated as late as possible. In the .NET Framework 4, assembly-level transparency calculation occurs sooner than it does in the .NET Framework 2.0. The only guarantee is that transparency calculation will occur by the time it is needed. This is similar to how the just-in-time (JIT) compiler can change the point when a method is compiled and any errors in that method are detected. Transparency calculation is invisible if your code does not have any transparency errors. Back to top
See Also
|
.NET Framework 4 Código transparente en seguridad La seguridad implica tres partes interrelacionadas: espacio aislado, permisos y cumplimiento. El espacio aislado hace referencia a la práctica de crear dominios aislados en los que determinado código se trata como de plena confianza y otro código está restringido a los permisos del conjunto de permisos concedido al espacio aislado. Se considera que el código de aplicación que se ejecuta dentro del conjunto de permisos concedido del espacio aislado es transparente; es decir, no puede realizar ninguna operación que pueda afectar a la seguridad. El conjunto de permisos concedido al espacio aislado está determinado por la evidencia. La evidencia identifica qué permisos concretos requieren los espacios aislados y qué tipos de espacios aislados se pueden crear. El cumplimiento hace referencia al hecho de permitir que el código transparente solo se ejecute dentro de su conjunto de permisos concedido. | Importante |
|---|
La directiva de seguridad era un elemento clave en versiones anteriores de .NET Framework. A partir de .NET Framework versión 4, la directiva de seguridad está obsoleta. La eliminación de la directiva de seguridad es independiente de la transparencia de seguridad. Para obtener información sobre los efectos de este cambio y recomendaciones sobre la mitigación, vea Compatibilidad con la directiva de seguridad de acceso del código y migración. |
En este tema se describe el modelo de transparencia de forma más detallada. Contiene las siguientes secciones:
Propósito del modelo de transparencia
La transparencia es un mecanismo de cumplimiento que separa el código que se ejecuta como parte de la aplicación del código que se ejecuta como parte de la infraestructura. La transparencia levanta una barrera entre código que puede realizar acciones con privilegios (código crítico), como llamar a código nativo, y código que no puede realizar dichas acciones (código transparente). El código transparente puede ejecutar comandos dentro de los límites del conjunto de permisos en el que está funcionando, pero no puede ejecutar, derivar ni contener código crítico. El objetivo principal de la exigencia de transparencia es proporcionar un mecanismo sencillo y eficaz para aislar grupos diferentes de código según los privilegios. Dentro del contexto del modelo de espacio aislado, estos grupos de privilegios son de plena confianza (es decir, no restringidos) o de confianza parcial (es decir, restringidos al conjunto de permisos concedido al espacio aislado). | Importante |
|---|
El modelo de transparencia transciende la seguridad de acceso del código. El compilador Just-In-Time (JIT) exige el cumplimiento de la transparencia y sigue en vigor sea cual sea el conjunto de permisos concedido a un ensamblado, incluida la plena confianza. |
La transparencia se introdujo en la versión 2.0 de .NET Framework para simplificar el modelo de seguridad y facilitar la escritura e implementación de bibliotecas y aplicaciones seguras. El código transparente también se utiliza en Microsoft Silverlight para simplificar el desarrollo de aplicaciones de confianza parcial. | Nota |
|---|
Al desarrollar una aplicación de confianza parcial, debe tener en cuenta los requisitos de permisos para los hosts de destino. Puede desarrollar una aplicación que utiliza recursos que algunos hosts no permiten. Esta aplicación se compilará sin errores, pero presentará un error al cargarla en el entorno hospedado. Si ha desarrollado la aplicación mediante Visual Studio, puede habilitar la depuración en confianza parcial o en un conjunto de permisos restringido del entorno de desarrollo. Para obtener más información, vea Cómo: Depurar una aplicación ClickOnce con permisos restringidos. La característica Calcular permisos proporcionada para aplicaciones ClickOnce también está disponible para cualquier aplicación de confianza parcial. |
Volver al principio
Especificar el nivel de transparencia
El atributo SecurityRulesAttribute de nivel de ensamblado selecciona explícitamente las reglas SecurityRuleSet que seguirá el ensamblado. Las reglas están organizadas en un sistema de niveles numéricos, donde los niveles más altos suponen un cumplimiento más estricto de las reglas de seguridad. Los niveles son los siguientes: La principal diferencia entre los dos niveles de transparencia es que el nivel 1 no exige el cumplimiento de las reglas de transparencia para llamadas de fuera del ensamblado y está previsto solo para compatibilidad. | Importante |
|---|
Solo debe especificar el nivel 1 de transparencia para cuestiones de compatibilidad; es decir, especifique el nivel 1 únicamente para código desarrollado con .NET Framework 3.5 o versiones anteriores, que utilice el atributo AllowPartiallyTrustedCallersAttribute o que no utilice el modelo de transparencia. Por ejemplo, utilice transparencia de nivel 1 para ensamblados de .NET Framework 2.0 que permiten llamadas de llamadores de confianza parcial (APTCA). Con el código que se desarrolla para .NET Framework 4, utilice siempre la transparencia de nivel 2. |
Transparencia de nivel 2La transparencia de nivel 2 se introdujo en .NET Framework versión 4. Los tres principios de este modelo son código transparente, código crítico para la seguridad y disponible desde código transparente y código crítico para la seguridad. El código transparente, sean cuales sean los permisos concedidos (incluso la plena confianza), solo puede llamar a otro código transparente o a código crítico para la seguridad y disponible desde código transparente. Si el código es de confianza parcial, solo puede realizar las acciones permitidas por el conjunto de permisos del dominio. El código transparente no puede hacer lo siguiente: Realizar una operación Assert o elevación de privilegios. Contener código no seguro o no comprobable. Llamar directamente a código crítico. Llamar a código nativo o código que tenga el atributo SuppressUnmanagedCodeSecurityAttribute. Llamar a un miembro que esté protegido por LinkDemand. Heredar de tipos críticos.
Además, los métodos transparentes no pueden invalidar los métodos virtuales críticos ni implementar métodos de interfaz críticos. El código crítico para la seguridad y disponible desde código transparente es de plena confianza pero es invocable por código transparente. Expone un área expuesta limitada de código de plena confianza. Las comprobaciones de corrección y seguridad se producen en código crítico para la seguridad y disponible desde código transparente. El código crítico para la seguridad puede llamar a cualquier código y es de plena confianza, pero no puede ser llamado por código transparente.
Transparencia de nivel 1El modelo de transparencia de nivel 1 se introdujo en la versión 2.0 de .NET Framework para permitir a los desarrolladores reducir la cantidad de código que está sujeta a una auditoría de seguridad. Aunque la transparencia de nivel 1 estaba públicamente disponible en la versión 2.0, se utilizó principalmente solo dentro de Microsoft para fines de auditoría de seguridad. Mediante anotaciones, los desarrolladores pueden declarar qué tipos y miembros pueden realizar elevaciones de seguridad y otras acciones de confianza (críticas para la seguridad) y cuáles no (transparentes en seguridad). El código que se identifica como transparente no requiere ningún grado elevado de auditoría de seguridad. La transparencia de nivel 1 indica que el cumplimiento de la transparencia se limita al interior del ensamblado. En otras palabras, cualquier tipo o miembro público que se identifica como crítico para la seguridad solo lo es dentro del ensamblado. Si desea exigir el cumplimiento de la seguridad para estos tipos y miembros cuando se les llama desde fuera del ensamblado, debe utilizar peticiones de vínculo para plena confianza. Si no lo hace, los tipos y miembros críticos para la seguridad públicamente visibles se tratan como críticos para la seguridad y disponibles desde código transparente y pueden ser llamados por código de confianza parcial fuera del ensamblado. El modelo de transparencia de nivel 1 tiene las siguientes limitaciones: Los tipos y miembros críticos para la seguridad que son públicos son accesibles desde código transparente en seguridad. Se exige el cumplimiento de las anotaciones de transparencia solo dentro de un ensamblado. Los tipos y miembros críticos para la seguridad deben utilizar peticiones de vínculo para exigir el cumplimiento de la seguridad para llamadas de fuera del ensamblado. No se exige el cumplimiento de reglas de herencia. El código transparente tiene el potencial para realizar acciones dañinas cuando se ejecuta en plena confianza.
Volver al principio
Cumplimiento de la transparencia
No se exige el cumplimiento de reglas de transparencia hasta que ésta se haya calculado. En ese momento, se produce InvalidOperationException si se infringe una regla de transparencia. El tiempo que se tarda en calcular la transparencia depende de varios factores y no se puede predecir. Se calcula lo más tarde posible. En .NET Framework 4, el cálculo de transparencia del nivel de ensamblado se produce antes que en .NET Framework 2.0. La única garantía es que el cálculo de transparencia se producirá en el momento en que sea necesario. Esto es similar al modo en que el compilador Just-In-Time (JIT) puede cambiar el punto cuando se compila un método y se detecta en éste cualquier error. El cálculo de la transparencia no es visible si su código no tiene ningún error de transparencia. Volver al principio
Vea también
|