Code transparent de sécurité, niveau 2
La transparence de niveau 2 a été introduite dans le .NET Framework version 4. Les trois composants de ce modèle sont le code transparent, le code critique sécurisé et le code critique de sécurité.
Le code transparent, notamment le code qui s'exécute avec une confiance totale, peut uniquement appeler un autre code transparent ou un code critique sécurisé. Il peut uniquement exécuter les actions autorisées par le jeu d'autorisations (s'il en existe un) de confiance partielle du domaine. Le code transparent ne peut pas effectuer les opérations suivantes :
Effectuer une Assert or élévation de privilège.
Contenir du code non sécurisé or non vérifiable.
Appeler directement du code critique.
Appeler du code natif ou du code possédant l'attribut SuppressUnmanagedCodeSecurityAttribute.
Appeler un membre qui est protégé par un LinkDemand.
Hériter de types critiques.
De plus, les méthodes transparentes ne peuvent pas substituer de méthodes virtuelles critiques ou implémenter des méthodes d'interface critiques.
Le code critique sécurisé a un niveau de confiance totale mais peut être appelé par du code transparent. Il expose une surface limitée de code de confiance totale. Les vérifications d'exactitude et de sécurité ont lieu dans le code critique sécurisé.
Le code critique de sécurité peut appeler tout code et a un niveau de confiance totale, mais il ne peut pas être appelé par du code transparent.
Cette rubrique contient les sections suivantes :
Comportements et exemples d'utilisation
Modèles de substitution
Règles d'héritage
Règles et informations supplémentaires
Comportements et exemples d'utilisation
Pour spécifier des règles .NET Framework 4 (transparence de niveau 2), utilisez l'annotation suivante pour un assembly :
[assembly: SecurityRules(SecurityRuleSet.Level2)]
Pour verrouiller les règles .NET Framework 2.0 (transparence de niveau 1), utilisez l'annotation suivante :
[assembly: SecurityRules(SecurityRuleSet.Level1)]
Si vous n'annotez pas d'assembly, les règles .NET Framework 4 sont utilisées par défaut. Toutefois, la meilleure pratique consiste à utiliser l'attribut SecurityRulesAttribute au lieu de dépendre de la valeur par défaut.
Annotation au niveau de l'assembly
Les règles suivantes s'appliquent à l'utilisation d'attributs au niveau de l'assembly :
Aucun attribut : si vous ne spécifiez pas d'attributs, le runtime interprète tout le code comme étant critique de sécurité, sauf si cet état entre en violation avec une règle d'héritage (par exemple, lors de la substitution ou de l'implémentation d'une méthode d'interface ou virtuelle transparente). Dans ces cas, les méthodes sont critiques sécurisées. Lorsque aucun attribut n'est spécifié, le Common Language Runtime détermine les règles de transparence à votre place.
SecurityTransparent : tout le code est transparent. L'assembly dans son ensemble ne fera rien de privilégié ou de non sécurisé.
SecurityCritical : tout le code présenté par les types de cet assembly est critique ; le reste du code est transparent. Ce scénario est similaire à la non-spécification d'attributs. Toutefois, le Common Language Runtime ne détermine pas automatiquement les règles de transparence. Par exemple, si vous substituez une méthode virtuelle ou abstraite ou implémentez une méthode d'interface, par défaut, cette méthode est transparente. Vous devez annoter explicitement la méthode comme SecurityCritical ou SecuritySafeCritical ; sinon, une exception TypeLoadException est levée au moment du chargement. Cette règle s'applique également lorsque la classe de base et la classe dérivée figurent toutes deux dans le même assembly.
AllowPartiallyTrustedCallers (niveau 2 uniquement) : tout le code est transparent par défaut. Toutefois, certains types et membres spécifiques peuvent avoir d'autres attributs.
Le tableau suivant compare le comportement de niveau d'assembly pour le niveau 2 avec le niveau 1.
Attribut d'assembly |
Niveau 2 |
Niveau 1 |
|---|---|---|
Aucun attribut sur un assembly partiellement fiable |
Les types et membres sont transparents par défaut, mais peuvent être critiques de sécurité ou critiques sécurisés. |
Tous les types et membres sont transparents. |
Pas d'attribut |
Lorsque aucun attribut n'est spécifié, le Common Language Runtime détermine les règles de transparence à votre place. Tous les types et membres sont critiques de sécurité, sauf lorsque cet état entre en violation avec une règle d'héritage. |
Sur un assembly d'un niveau de confiance totale (dans le Global Assembly Cache ou identifié en tant que fiable dans le AppDomain), tous les types sont transparents et tous les membres sont critiques sécurisés. |
SecurityTransparent |
Tous les types et membres sont transparents. |
Tous les types et membres sont transparents. |
SecurityCritical(SecurityCriticalScope.Everything) |
Non applicable. |
Tous les types et membres sont critique de sécurité. |
SecurityCritical |
Tout le code présenté par les types de cet assembly est critique ; le reste du code est transparent. Si vous substituez une méthode virtuelle ou abstraite ou implémentez une méthode d'interface, vous devez annoter explicitement la méthode comme SecurityCritical ou SecuritySafeCritical. |
L'ensemble du code est transparent par défaut. Toutefois, certains types et membres spécifiques peuvent avoir d'autres attributs. |
Annotation de type et de membre
Les attributs de sécurité appliqués à un type s'appliquent également aux membres présentés par le type. Toutefois, ils ne s'appliquent pas aux substitutions virtuelles ou abstraites de la classe de base ou des implémentations d'interface. Les règles suivantes s'appliquent à l'utilisation d'attributs au niveau des types et des membres :
SecurityCritical : le type ou le membre est critique et peut être appelé uniquement par du code de confiance totale. Les méthodes introduites dans un type critique de sécurité sont critiques.
.gif "Remarque importante")
ImportantLes méthodes virtuelles et abstraites présentées dans des interfaces ou des classes de base, et substituées ou implémentées dans une classe critique de sécurité, sont transparentes par défaut.Elles doivent être identifiées comme SecuritySafeCritical ou SecurityCritical.
SecuritySafeCritical : le type ou le membre est critique sécurisé. Toutefois, le type ou le membre peut être appelé à partir de code transparent (partiellement approuvé) et a les mêmes capacité que tout autre code critique. Le code doit être audité dans le cadre de la sécurité.
Retour au début
Modèles de substitution
Le tableau suivant indique les substitutions de méthodes autorisées pour la transparence de niveau 2.
Membre d'interface/virtuel de base |
Substitution/interface |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
SafeCritical |
Transparent |
SafeCritical |
SafeCritical |
Critical |
Critical |
Retour au début
Règles d'héritage
Dans cette section, l'ordre suivant est assigné au code Transparent, Critical et SafeCritical en fonction de l'accès et des fonctionnalités :
Transparent < SafeCritical < Critical
Règles pour les types : de gauche à droite, l'accès devient plus restrictif. Les types dérivés doivent être au moins aussi restrictifs que le type de base.
Règles pour les méthodes : les méthodes dérivées ne peuvent pas changer l'accessibilité depuis la méthode de base. Pour le comportement par défaut, toutes les méthodes dérivées qui ne sont pas annotées sont Transparent. Les dérivés des types critiques lèvent qu'une exception si la méthode substituée n'est pas annotée explicitement en tant que SecurityCritical.
Le tableau suivant indique les modèles d'héritage de type autorisés.
Classe de base |
La classe dérivée peut être |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
Transparent |
Critical |
SafeCritical |
SafeCritical |
SafeCritical |
Critical |
Critical |
Critical |
Le tableau suivant indique les modèles d'héritage de type non autorisés.
Classe de base |
La classe dérivée ne peut pas être |
|---|---|
SafeCritical |
Transparent |
Critical |
Transparent |
Critical |
SafeCritical |
Le tableau suivant indique les modèles d'héritage de méthode autorisés.
Méthode de base |
La méthode dérivée peut être |
|---|---|
Transparent |
Transparent |
Transparent |
SafeCritical |
SafeCritical |
Transparent |
SafeCritical |
SafeCritical |
Critical |
Critical |
Le tableau suivant indique les modèles d'héritage de méthode non autorisés.
Méthode de base |
La méthode dérivée ne peut pas être |
|---|---|
Transparent |
Critical |
SafeCritical |
Critical |
Critical |
Transparent |
Critical |
SafeCritical |
.gif "Remarque") Remarque |
|---|
Ces règles d'héritage s'appliquent aux types et membres de niveau 2.Les types des assemblys de niveau 1 peuvent hériter des types et membres critiques de sécurité de niveau 2.Par conséquent, les types et membres de niveau 2 doivent disposer de demandes d'héritage séparées pour les héritiers de niveau 1. |
Retour au début
Règles et informations supplémentaires
Prise en charge de LinkDemand
Le modèle de transparence de niveau 2 remplace le LinkDemand par l'attribut SecurityCriticalAttribute. Dans le code hérité (niveau 1), un LinkDemand est automatiquement traité comme un Demand.
Réflexion
L'appel d'une méthode critique ou la lecture d'un champ critique déclenche une demande de confiance totale (comme si vous appeliez une méthode ou un champ privé(e)). Par conséquent, le code de confiance totale peut appeler une méthode critique, tandis que le code de confiance partielle ne peut pas.
Les propriétés suivantes ont été ajoutées à l'espace de noms System.Reflection pour déterminer si le type, la méthode ou le champ est SecurityCritical, SecuritySafeCritical ou SecurityTransparent : IsSecurityCritical, IsSecuritySafeCritical et IsSecurityTransparent. Utilisez ces propriétés pour déterminer la transparence à l'aide de la réflexion au lieu de rechercher la présence de l'attribut. Les règles de transparence sont complexes, et la recherche de l'attribut peut ne pas être suffisante.
| Remarque |
|---|
Une méthode SafeCritical retourne true à la fois pour IsSecurityCriticalet IsSecuritySafeCritical, car SafeCritical est réellement critique (il a les mêmes fonctionnalités que le code critique, mais il peut être appelé à partir de code transparent). |
Les méthodes dynamiques héritent de la transparence des modules auxquels elles sont attachées. Elles n'héritent pas de la transparence du type (si elles sont attachées à un type).
Ignorer la vérification en cas de confiance totale
Vous pouvez ignorer la vérification pour les assemblys transparents d'un niveau de confiance totale en affectant à la propriété SkipVerificationInFullTrust la valeur true dans l'attribut SecurityRulesAttribute :
[assembly: SecurityRules(SecurityRulesSet.Level2, SkipVerificationInFullTrust = true)]
La propriété SkipVerificationInFullTrust a la valeur false par défaut. Elle doit donc avoir la valeur true pour ignorer la vérification. Ceci doit être fait à des fins d'optimisation uniquement. Vous devez vous assurer que le code transparent de l'assembly est vérifiable à l'aide de l'option transparent de l'outil PEVerify.
Retour au début