Código transparente en seguridad, nivel 2

La 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, incluido el código que se está ejecutando como de 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. Solamente puede realizar acciones permitidas por el conjunto de permisos de confianza parcial del dominio (si existe alguno). 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 con 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.

Este tema contiene las siguientes secciones:

• Ejemplos de uso y comportamientos

• Modelos de reemplazos

• Reglas de herencia

• Información adicional y reglas

Ejemplos de uso y comportamientos

Para especificar reglas de .NET Framework 4 (transparencia de nivel 2), utilice la siguiente anotación para un ensamblado:

[assembly: SecurityRules(SecurityRuleSet.Level2)]

Para ceñirse a las reglas de transparencia de .NET Framework 2.0 (transparencia de nivel 1), utilice la siguiente anotación:

[assembly: SecurityRules(SecurityRuleSet.Level1)]

Si no anota un ensamblado, se utilizan las reglas de .NET Framework 4 de forma predeterminada. Sin embargo, el procedimiento recomendado es utilizar el atributo SecurityRulesAttribute en lugar de depender del valor predeterminado.

Anotación Assemblywide

Se aplican las reglas siguientes al uso de atributos en el nivel de ensamblado:

• Ningún atributo: si no especifica ningún atributo, el runtime interpreta todo el código como crítico para la seguridad, excepto cuando al ser crítico para la seguridad infrinja una regla de herencia (por ejemplo, al invalidar o implementar un método virtual o de interfaz transparente). En esos casos, los métodos son críticos para la seguridad y disponibles desde código transparente. Si no se especifica ningún atributo, Common Language Runtime determinará las reglas de transparencia para el usuario.

• SecurityTransparent: todo el código es transparente; el ensamblado completo no hará nada que tenga privilegios o que no sea seguro.

• SecurityCritical: todo el código introducido por tipos en este ensamblado es crítico; todo el código restante es transparente. Este escenario equivale a no especificar atributo alguno; sin embargo, Common Language Runtime no determina las reglas de transparencia automáticamente. Por ejemplo, si invalida un método virtual o abstracto o implementa un método de interfaz, de forma predeterminada, ese método es transparente. Debe anotar explícitamente el método como SecurityCritical o SecuritySafeCritical; de lo contrario, se producirá TypeLoadException en el momento de la carga. Esta regla también se aplica cuando la clase base y la clase derivada están en el mismo ensamblado.

• AllowPartiallyTrustedCallers (solo nivel 2): todo el código se establece de forma predeterminada como transparente. No obstante, cada tipo o miembro puede tener otros atributos.

En la siguiente tabla se compara el comportamiento de nivel del ensamblado para el nivel 2 con el nivel 1.

Anotación de tipos y de miembros

Los atributos de seguridad que se aplican a un tipo también se aplican a los miembros introducidos por el tipo. Sin embargo, no se aplican a reemplazos virtuales o abstractos de la clase base o implementaciones de interfaces. Se aplican las reglas siguientes al uso de atributos en el nivel de tipo y miembro:

• SecurityCritical: el tipo o miembro es crítico y puede ser llamado solo por código de plena confianza. Los métodos que se introducen en un tipo crítico para la seguridad son críticos.

  Importante
  Los métodos virtuales y abstractos que se introducen en clases base o interfaces, y que se invalidan o implementan en una clase crítica para la seguridad son transparentes de forma predeterminada.Se deben identificar como SecuritySafeCritical o SecurityCritical.

• SecuritySafeCritical: el tipo o miembro es crítico para la seguridad y disponible desde código transparente. Sin embargo, el tipo o miembro puede ser llamado desde código transparente (de confianza parcial) y ser tan capaz como cualquier otro código crítico. Se debe auditar el código para mayor seguridad.

Volver al principio

Modelos de reemplazos

La siguiente tabla muestra los reemplazos de método permitidos para la transparencia de nivel 2.

Volver al principio

Reglas de herencia

En esta sección, se asigna el siguiente orden al código Transparent, Critical y SafeCritical basándose en el acceso y las capacidades:

Transparent < SafeCritical < Critical

• Reglas para tipos: de izquierda a derecha, el acceso se vuelve más restrictivo. Los tipos derivados deben ser por lo menos tan restrictivos como el tipo base.

• Reglas para métodos: los métodos derivados no pueden cambiar la accesibilidad del método base. Para el comportamiento predeterminado, todos los métodos derivados que no estén anotados son Transparent. Los derivados de tipos críticos provocan una excepción que se produce si el método invalidado no está explícitamente anotado como SecurityCritical.

En la siguiente tabla se muestran los modelos de herencia de tipos permitidos.

En la siguiente tabla se muestran los modelos de herencia de tipos no permitidos.

En la siguiente tabla se muestran los modelos de herencia de métodos permitidos.

En la siguiente tabla se muestran los modelos de herencia de métodos no permitidos.

Nota
Estas reglas de herencia se aplican a tipos y miembros de nivel 2.Los tipos en ensamblados de nivel 1 pueden heredar de tipos y miembros críticos para la seguridad de nivel 2.Por consiguiente, los tipos y miembros de nivel 2 deben tener peticiones de herencia independientes para los herederos de nivel 1.

Volver al principio

Información adicional y reglas

Compatibilidad con LinkDemand

El modelo de transparencia de nivel 2 reemplaza LinkDemand por el atributo SecurityCriticalAttribute. En código heredado (nivel 1), LinkDemand se trata automáticamente como Demand.

Reflexión

Al invocar un método crítico o leer un campo crítico, se activa una demanda de plena confianza (igual que si estuviera invocando un método o campo privado). Por consiguiente, el código de plena confianza puede invocar un método crítico, mientras que el código de confianza parcial no puede.

Se han agregado las siguientes propiedades al espacio de nombres System.Reflection para determinar si el tipo, método o campo es SecurityCritical, SecuritySafeCritical o SecurityTransparent: IsSecurityCritical, IsSecuritySafeCritical e IsSecurityTransparent. Utilice estas propiedades para determinar la transparencia usando la reflexión en lugar de comprobando la presencia del atributo. Las reglas de transparencia son complejas y es posible que la comprobación del atributo no sea suficiente.

Nota
Un método SafeCritical devuelve true para IsSecurityCriticalIsSecuritySafeCritical, porque SafeCritical es de hecho crítico (tiene las mismas capacidades que el código crítico, pero se le puede llamar desde código transparente).

Los métodos dinámicos heredan la transparencia de los módulos al que están adjuntos; no heredan la transparencia del tipo (si están adjuntos a un tipo).

Omitir la comprobación en plena confianza

Puede omitir la comprobación para los ensamblados transparentes de plena confianza estableciendo la propiedad SkipVerificationInFullTrust en true en el atributo SecurityRulesAttribute:

[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]

La propiedad SkipVerificationInFullTrust es false de forma predeterminada, por lo que la propiedad debe estar establecida en true para omitir la comprobación. Esto solo se debe hacer para fines de optimización. Debe asegurarse de que el código transparente del ensamblado sea comprobable utilizando la opción transparent en la herramienta PEVerify.

Volver al principio

Vea también

Conceptos

Código transparente en seguridad, nivel 1

Cambios de seguridad en .NET Framework 4