Partager via

Restrictions du modèle de programmation de l'intégration du CLR

  • Article

Lorsque vous créez une procédure stockée managée ou un autre objet de base de données managée, certaines vérifications de code sont effectuées par SQL Server effectue des vérifications sur l’assembly de code managé lors de son premier enregistrement dans la base de données, à l’aide de l’instruction CREATE ASSEMBLY , ainsi qu’au moment de l’exécution. Le code managé est également vérifié pendant l'exécution, car dans un assembly il peut y avoir des chemins d'accès de code qui peuvent ne jamais être atteints pendant l'exécution. Cela fournit la souplesse nécessaire pour inscrire notamment des assemblys tiers, afin qu'un assembly ne soit pas bloqué là où il y a du code « potentiellement dangereux » conçu pour s'exécuter dans un environnement client, mais ne soit jamais exécuté dans le CLR hébergé. Les exigences que le code managé doit respecter varient selon que l’assembly est inscrit en tant que SAFE, EXTERNAL_ACCESSou UNSAFE, SAFE étant le plus strict, et sont listés ci-dessous.

En plus des restrictions imposées sur les assemblys de code managé, des autorisations de sécurité du code sont également accordées. Le Common Language Runtime (CLR) prend en charge un modèle de sécurité appelé sécurité d'accès du code pour le code managé. Dans ce modèle, les autorisations sont accordées aux assemblys selon l'identité du code. Les assemblys SAFE, EXTERNAL_ACCESS et UNSAFE ont des autorisations de sécurité d'accès du code différentes. Pour plus d’informations, consultez Sécurité d’accès au code d’intégration DU CLR.

Contrôles CREATE ASSEMBLY

Lorsque l'instruction CREATE ASSEMBLY est exécutée, les contrôles suivants sont effectués pour chaque niveau de sécurité. Si un contrôle échoue, CREATE ASSEMBLY échoue avec un message d'erreur.

Global (tout niveau de sécurité)

Tous les assemblys référencés doivent satisfaire un ou plusieurs des critères suivants :

  • L'assembly est déjà inscrit dans la base de données.

  • L'assembly est l'un des assemblys pris en charge. Pour plus d’informations, consultez Bibliothèques .NET Framework prises en charge.

  • Vous utilisez CREATE ASSEMBLY FROM<l’emplacement>, et tous les assemblys référencés et leurs dépendances sont disponibles à l’emplacement<>.

  • Vous utilisez des CREATE ASSEMBLY FROM<octets ...>, et toutes les références sont spécifiées via des octets séparés par l’espace.

EXTERNAL_ACCESS

Tous les assemblys EXTERNAL_ACCESS doivent répondre aux critères suivants :

  • Les champs statiques ne sont pas utilisés pour stocker des informations. Les champs statiques en lecture seule sont autorisés.

  • Le test PEVerify est réussi. L'outil PEVerify (peverify.exe), qui vérifie que le code MSIL et les métadonnées associées satisfont les spécifications de sécurité de type, est fourni dans le Kit de développement SDK .NET Framework.

  • La synchronisation, par exemple avec la classe SynchronizationAttribute, n'est pas utilisée.

  • Les méthodes finaliseurs ne sont pas utilisées.

Les attributs personnalisés suivants sont interdits dans les assemblys EXTERNAL_ACCESS :

  • System.ContextStaticAttribute

  • System.MTAThreadAttribute

  • System.Runtime.CompilerServices.MethodImplAttribute

  • System.Runtime.CompilerServices.CompilationRelaxationsAttribute

  • System.Runtime.Remoting.Contexts.ContextAttribute

  • System.Runtime.Remoting.Contexts.SynchronizationAttribute

  • System.Runtime.InteropServices.DllImportAttribute

  • System.Security.Permissions.CodeAccessSecurityAttribute

  • System.Security.SuppressUnmanagedCodeSecurityAttribute

  • System.Security.UnverifiableCodeAttribute

  • System.STAThreadAttribute

  • System.ThreadStaticAttribute

SAFE

  • Toutes les conditions d'assembly EXTERNAL_ACCESS sont vérifiées.

Contrôles d'exécution

Pendant l'exécution, les conditions suivantes sont vérifiées pour l'assembly de code. Si l'une de ces conditions est remplie, le code managé n'est pas autorisé à s'exécuter et une exception est levée.

UNSAFE

Le chargement d’un assembly , soit explicitement en appelant la System.Reflection.Assembly.Load() méthode à partir d’un tableau d’octets, soit implicitement via l’utilisation d’un espace de Reflection.Emit noms, n’est pas autorisé.

EXTERNAL_ACCESS

Toutes les conditions UNSAFE sont vérifiées.

Tous les types et méthodes annotés avec les valeurs d'attribut de protection de l'hôte suivantes dans la liste d'assemblys prise en charge sont interdits.

  • SelfAffectingProcessMgmt

  • SelfAffectingThreading

  • Synchronization

  • SharedState

  • ExternalProcessMgmt

  • ExternalThreading

  • SecurityInfrastructure

  • MayLeakOnAbort

  • Interface utilisateur du service

Pour plus d’informations sur les HPA et une liste des types et membres non autorisés dans les assemblys pris en charge, consultez Host Protection Attributes and CLR Integration Programming.

SAFE

Toutes les conditions EXTERNAL_ACCESS sont vérifiées.

Voir aussi

Bibliothèques .NET Framework prises en charge
Sécurité d'accès du code de l'intégration du CLR
Attributs de protection de l'hôte et programmation de l'intégration CLR
Création d'un assembly