Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Fonctionnement de Code Access Security

Code Access Security (CAS) est une fonctionnalité du Framework .Net qui permet aux développeurs de rendre leurs applications plus sécurisées et moins vulnérables aux attaques.

Il est ainsi possible de restreindre les permissions de façon très précise. Il existe un ensemble de classes implémentant IPermission qui permettent de contrôler beaucoup de choses (FileIOPermission, RegistryPermission, ReflectionPermission, WebPermission, PrintingPermission...).

Le principe est le suivant : par exemple, lorsque vous appelez File.Open pour ouvrir un fichier, cette méthode va faire une demande de permission pour savoir si les appelants ont le droit d'ouvrir ce fichier. Le CLR va alors soit ouvrir le fichier (comme prévu), soit lever une SecurityException. Je vais décrire le mécanisme qui décide si la demande de permission réussit, ou pas.

Les permissions d'un Assembly

Au chargement d'un Assembly, le CLR va calculer l'ensemble des permissions accordées à cet Assembly. Une fois chargé en mémoire, ces permissions ne seront plus modifiables.

Plusieurs choses interviennent dans le calcul de ces permissions.

  • Au chargement de l'Assembly, une preuve (Evidence) est fournie au CLR. Le CLR consulte alors la stratégie de sécurité de l'ordinateur, et il en déduit un ensemble de permissions.
    Par exemple, un assembly venant de la zone Internet aura un ensemble de permissions très restreint, alors qu'un assembly venant de la zone MyComputer aura toutes les permissions.
  • Il se peut que l'AppDomain dans lequel est chargé l'Assembly n'ait qu'un ensemble restreint de permission (voir mon précédent article). Cela peut avoir pour effet de diminuer les permissions de l'Assembly.
  • Enfin, l'Assembly lui même peut restreindre l'ensemble des permissions qu'il accepte, grâce à des attributs, par exemple :
    [assembly: FileIOPermission(SecurityAction.RequestRefuse, Write = @"C:\")]
    [assembly: RegistryPermission(SecurityAction.RequestOptional, Read = @"HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0")]

On peut savoir à tout moment si l'Assembly courant dispose d'un droit, ou non, en utilisant la méthode statique SecurityManager.IsGranted() :

FileIOPermission permission = new FileIOPermission(PermissionState.Unrestricted);
bool isGranted = SecurityManager.IsGranted(permission);

Les demandes et le parcours de pile

Une demande s'applique à une certaine permission (ou ensemble de permissions). Pour savoir si une demande réussit ou échoue, le CLR va parcourir la pile des appelants de la méthode qui effectue la demande. Si une méthode appelante se trouve dans un assembly qui ne dispose pas de la permission, la demande échoue. Si tous les appelants ont la permission, elle réussit.

Supposons que la méthode Main appelle A1, A1 appelle A2, A2 appelle B1, etc... Main, A1 et A2 sont dans un assembly A ; B1, B2 et B3 dans un assembly B et C1, C2 et C3 dans un assembly C. C3 fait une demande sur une permission P. Les assemblies en vert disposent de cette permission et ceux en rouge n'en disposent pas.


A gauche, tous les appelants ont la permission donc la demande réussit. A droite l'assembly A n'a pas la permission donc la demande échoue

Il faut bien noter que la méthode qui effectue la demande n'est pas vérifiée mais seulement ses appelants, on peut donc avoir les situations suivantes :

Mais il n'est en général pas nécessaire de faire de demandes de permission sauf si vous implémentez des permissions personnalisées. Les assemblies effectuant les demandes sont le plus souvent ceux du Framework.

Les modificateurs de parcours de pile

Pour ajouter plus de flexibilité à ce système, il existe ce qu'on appelle les modificateurs de parcours de pile. Ils ne modifient pas les permissions accordées aux assemblies. Ils peuvent seulement modifier dans certaines conditions le résultat d'un parcours de pile. Ils s'appliquent à une certaine permission (ou ensemble de permissions). Il en existe 3 :

  • Deny : Stoppe le parcours de pile et fait échouer la demande si l'intersection de la permission demandée et de la permission interdite est non vide.
  • PermitOnly : Revient à faire un Deny sur toutes les permissions, sauf celle indiquée (y compris celles d'un autre type).


A gauche, le fonctionnement sans Deny, la demande réussit. A droite, elle échoue à cause du Deny

  • Assert : Stoppe le parcours de pile et fait réussir la demande si la permission demandée est incluse dans la permission indiquée dans Assert.


A gauche, le fonctionnement sans Assert, la demande échoue car A n'a pas la permission. A droite, elle réussit à cause du Assert, les méthodes qui appellent B2 ne sont pas vérifiées

Pour qu'une méthode utilise Assert sur une permission, il est nécessaire que l'assembly qui la contient dispose de cette permission (assemblies verts sur les schémas). De plus, il faut que l'assembly dispose de la permission de faire des assertions (ce n'est pas le cas des Assemblies provenant de la zone Internet par exemple).

Assert doit donc être utilisé avec précaution car un assembly qui ne dispose pas d'une permission peut appeler un autre assembly qui fait un Assert sur cette permission. L'assembly appelant peut donc accéder à des ressources à des fins malveillantes, sans en avoir la permission.

Enfin, vous pouvez voir qu'il est inutile d'utiliser Deny sur une permission dans un assembly A avant d'appeler une méthode d'un assembly B qui dispose de cette permission. En effet, B peut faire Assert sur cette permission. Le parcours de pile s'arrêtera à l'Assert de B (en réussissant) et n'ira pas jusqu'au Deny de A. Il ne sera utile d'appeler Deny dans A que si B n'a pas le droit de faire d'assertions.

Publié dimanche 22 octobre 2006 21:17 par RaptorXP
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: Fonctionnement de Code Access Security

excellent article prochainement relayé dans la newsletter MSDN!!

lundi 23 octobre 2006 15:23 by malabar

# re: Fonctionnement de Code Access Security

Woow, super, merci :D !!

lundi 23 octobre 2006 16:46 by RaptorXP

# re: Fonctionnement de Code Access Security

Ca sens la certification 70-536 !!!! Félicitations d'ailleurs pour l'avoir eu !

++

vendredi 27 octobre 2006 23:22 by neodante
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01