LA SÉCURITÉ D'ACCÈS AU CODE

Le Framework définit cinq zones de sécurité :

• sites sensibles : sites identifiés ainsi dans votre navigateur ;
• internet : application s'exécutant depuis internet hors sites sensibles ou de confiance ;
• sites de confiance : sites identifiés ainsi dans votre navigateur ;
• intranet : applications installées sur l'intranet du poste ;
• poste de travail : applications installées sur l'ordinateur.

Ces zones de sécurité ne font rien par elles-mêmes, elles déterminent juste un niveau de confiance auquel est associé un jeu d'autorisations. C'est celui-ci qui détermine les ressources accessibles.

Comme nous le verrons un peu plus loin, il est possible d'ajouter de nouvelles zones de sécurité le cas échéant.

Parfois appelé aussi niveau de confiance. Il existe des jeux nommés déjà définis :

Les jeux d'autorisations intranet et internet possèdent des autorisations qui sont définies par les stratégies de sécurité du poste de travail, de l'entreprise et/ou de l'utilisateur.

Le Framework expose les autorisations suivantes :

Chacune de ces classes peut gérer un grand nombre d'autorisations spécifiques avec plusieurs types d'accès différents. Par exemple chaque variable d'environnement peut être définie séparément, pour un accès en lecture et/ou en écriture ou pour en interdire l'accès.

Le nombre de jeux de permissions réalisable est donc gigantesque.

Il existe de nombreux outils pour manipuler ces concepts de sécurité. Le plus simple à utiliser se trouve dans le panneau de configuration, c'est l'outil de configuration du Framework.

Il se présente sous la forme suivante :

À partir de ce gestionnaire, il est possible d'ajouter des zones de sécurité, de créer et/ou de modifier des jeux de permissions, etc.

Par exemple, je peux créer assez facilement un jeu d'autorisation.

Pour cela il suffit de sélectionner « Jeux d'autorisations » dans le volet de gauche, de cliquer sur le lien « Créer un nouveau jeu d'autorisations ». Puis de suivre les instructions, par exemple :

Lors du chargement d'un assembly, le runtime commence par évaluer les preuves fournies pas l'assembly. Comme nous l'avons dit, celles-ci sont toujours aux moins fixées par la zone de sécurité d'où s'exécute l'assembly, mais il peut en posséder d'autres, telles qu'un nom fort, un chemin d'accès spécifique, un certificat, etc.

Selon ces preuves, le runtime calcule un jeu d'autorisations. Si à un moment votre code appelle une ressource sans en avoir l'autorisation, il y a levée d'une exception.

Commençons à définir, les règles de fonctionnement.

Règle n° 1 : c'est toujours la stratégie de sécurité qui attribue les autorisations.

Autrement dit, vous n'avez pas la certitude qu'un code fonctionnant sur un poste avec ses preuves fonctionnera sur un autre poste avec les mêmes preuves, car la stratégie de sécurité peut différer d'un poste à l'autre.

Règle n° 2 : on ne peut pas obtenir par le code des autorisations non données par la stratégie de sécurité.

Votre code ne peut pas augmenter ses privilèges.

Règle n° 3 : c'est au développeur de gérer les exceptions de sécurité.

Sans gestion de la sécurité, le programme s'arrêtera de fonctionner lors de l'appel de la ressource interdite.

Pour pouvoir anticiper sur ces erreurs éventuelles, le Framework met à votre disposition des mécanismes de demandes d'autorisation que nous verrons un peu plus loin.

Comme vous l'avez sûrement remarqué, il y a un défaut à la cuirasse. Si la principale source de preuve est l'origine, tout assembly installé sur le poste de travail puis exécuté recevra le jeu d'autorisations maximales. Tout comme pour la sécurité du système d'exploitation, il incombe à l'utilisateur de savoir ce qu'il fait.

Par extension, on pourrait croire qu'un code s'exécutant d'une zone de sécurité restreinte peut augmenter ses privilèges en appelant un assembly installé sur le poste de travail. Ceci est faux, car le Framework implémente un contrôle de sécurité des appelants appelé communément « parcours de pile ».

Dans le principe, lors de l'appel d'une ressource protégée par un code managé, le CLR parcourt en remontant la pile des appelants de la méthode qui sollicite la ressource. Si un de ces appelants n'a pas l'autorisation nécessaire, l'appel de la méthode échoue et une exception est levée. Il est possible d'influer sur le parcours de pile par le code.

Comme la règle 2 nous le dit, le contrôle des autorisations ne change rien au fait qu'une ressource interdite le sera, mais permet uniquement de savoir quand l'exception sera levée et traitée.

Pour comprendre cela, envisageons le cas suivant. Je crée une application de type WinForms qui lit un fichier XML (un dataset) et l'affiche dans une grille. Le code est aussi simple que :

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim MonDS As New Data.DataSet("biblio")
        MonDS.ReadXml("d:\tutoriel\pubs.xml", XmlReadMode.ReadSchema)
        Me.DataGrid1.DataSource = MonDS.Tables(0)
    End Sub

Comme le fichier existe bien et sur mon poste de travail le code s'exécute correctement, j'affiche bien ma table dans ma grille. Maintenant, j'uploade l'exécutable sur internet. Avec mon navigateur, je vais sélectionner cet exécutable.

Je vais recevoir un premier message d'alerte de la forme :

Comme nous l'avons vu, il est maintenant plus sûr d'exécuter le code distant que de l'enregistrer sur le disque, puisqu'une fois sur le disque dur, il sera considéré comme un code de confiance totale. Je clique donc sur le bouton « Exécuter ».

Le navigateur m'envoie un deuxième message d'erreur, tel que :

Celui-ci est dû à l'absence de certificat de mon exécutable. Il y aurait beaucoup à dire sur la sécurité et les certificats, cependant demander l'exécution d'un code sans certificat peut déclencher l'apparition de cette boite de dialogue selon le paramétrage du navigateur. Je clique donc une nouvelle fois sur « Exécuter » et j'obtiens :

Nous voyons bien que la stratégie de sécurité a joué son rôle et qu'un code issu de la zone de sécurité « internet » ne peut pas utiliser des ressources de fichier locales. À ce moment l'erreur se produit bien sur la ligne :

MonDS.ReadXml("d:\tutoriel\pubs.xml", XmlReadMode.ReadSchema)

Si vous voulez en être sûr, il suffit d'ajouter la ligne :

MessageBox.Show("je charge le dataset maintenant")

juste avant l'appel de ReadXML. Dans ce cas vous verrez apparaître la boite de message puis l'erreur.

Le fait que cette boite de dialogue s'affiche alors que le code va et doit lever une exception n'est pas une bonne chose. Pour éviter le problème, on procède généralement à des vérifications d'autorisation.

IV-A-1. Sécurité déclarative▲

<Assembly: Security.Permissions.FileIOPermission(Security.Permissions.SecurityAction.RequestMinimum, _
 Read:="d:\tutoriel\pubs.xml")> 
<Assembly: Security.Permissions.FileIOPermission(Security.Permissions.SecurityAction.RequestOptional, _
 Write:="d:\tutoriel\pubs.xml")>

IV-A-2. Sécurité impérative▲

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim MonDS As New Data.DataSet("biblio")
        MessageBox.Show("je charge le dataset maintenant")
        Dim MaPerm As New Security.Permissions.FileIOPermission(Security.Permissions.PermissionState.Unrestricted, _
 "d:\tutoriel\pubs.xml")
        Try
            MaPerm.Demand()
        Catch ex As Exception
            MessageBox.Show("vous n'avez pas l'autorisation nécessaire", "Erreur", _
 MessageBoxButtons.OK, MessageBoxIcon.Error)
            Me.Close()
        End Try
        MonDS.ReadXml("d:\tutoriel\pubs.xml", XmlReadMode.ReadSchema)
        Me.DataGrid1.DataSource = MonDS.Tables(0)
    End Sub

Dans les cas comme celui-là, on a trop souvent tendance à prendre des mesures disproportionnées par rapport au problème. Bien sûr mon exemple est loin d'être un cas réel, car on se demande bien quel serait l'intérêt d'un tel code. Cependant pour contourner les problèmes, on a trop souvent tendance à vouloir modifier la stratégie de sécurité ou de forcer l'installation sur le poste de travail. Ce qui nous mène à la règle suivante :

Règle n° 4 : l'ignorance et la fainéantise sont les deux plus grandes failles de sécurité.

En effet, avant d'envisager forcément un octroi démesuré de droit sur la zone « internet » ou de forcer l'installation locale, il est plus sage de définir un ou plusieurs nouveaux groupes de code sur lesquels on appliquera une accumulation de preuve donnant droit à des accès. Ainsi dans mon cas, je pourrais créer un jeu d'autorisations donnant accès à mon fichier XML, puis créer un groupe de code qui vérifierait le nom fort et le site d'origine de l'appelant et en cas de concordance lui octroyer ce jeu d'autorisations. Bien sûr, cela demande d'intervenir sur la stratégie de sécurité du poste, ce qui peut être lourd si vous ciblez de nombreux postes, mais il est possible de préparer des fichiers XML permettant de simplifier l'opération.

Dans certains cas, on peut aussi envisager des stratégies de déploiement particulières, d'utiliser le stockage isolé, etc.

La sécurité repose donc sur le parcours de la pile des appelants. Dans certains cas, il peut être intéressant de modifier l'action de celle-ci, sous réserve de prendre en charge les implications de sécurité. Ces opérations qu'on retrouve sous le nom de substitution de vérification de sécurité sont de deux sortes.

IV-C-1. Assert▲

IV-C-2. PermitOnly et Deny▲

IV-C-3. Règles d'utilisation▲

IV-C-4. Exemple▲

Imports System.Security
Imports System.Data
Imports System.IO
<Assembly: AllowPartiallyTrustedCallers()> 
Public Class DtsXML
 
    Private m_FileName As String = ""
 
    Public Sub New()
 
    End Sub
 
    Public Sub New(ByVal Fichier As String)
        Me.NomFichier = Fichier
    End Sub
 
    Public Property NomFichier() As String
        Get
            Return m_FileName
        End Get
        Set(ByVal Value As String)
            m_FileName = Value
        End Set
    End Property
 
    Public Function ExtractDataset() As DataSet
 
        If Me.NomFichier.Length = 0 OrElse Me.NomFichier.EndsWith("xml") = False Then
            Throw New ArgumentException("Le nom de fichier n'est pas valide")
            Return Nothing
        End If
        Dim MonDts As New DataSet
        Dim pAssert As New Permissions.FileIOPermission(Permissions.FileIOPermissionAccess.Read, Me.NomFichier)
        Dim pDeny As New Permissions.FileDialogPermission(Permissions.PermissionState.Unrestricted)
        pAssert.Assert()
        pDeny.Deny()
        Try
            MonDts.ReadXml(Me.NomFichier, XmlReadMode.ReadSchema)
        Catch ex As FileNotFoundException
            Throw New ApplicationException("Le fichier" & Me.NomFichier & " n'est pas accessible")
        Catch ex As Xml.XmlException
            Throw New ApplicationException("Le fichier " & Me.NomFichier & " n'est pas un fichier xml valide")
        Finally
            pAssert.RevertAssert()
            pDeny.RevertDeny()
        End Try
        Return MonDts
    End Function
 
End Class

    Private Sub cmdChargement_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _
                                                                       Handles cmdChargement.Click
        Dim MonDS As New DataSet
        Dim objExtr As New clsDtsXML.DtsXML("d:\tutoriel\pubs.xml")
        Try
            MonDS = objExtr.ExtractDataset
            Me.DataGrid1.DataSource = MonDS.Tables(0)
        Catch ex As Exception
            MessageBox.Show("Echec de l'extraction " & vbCrLf & ex.Message, "Erreur", _
            MessageBoxButtons.OK, MessageBoxIcon.Error)
        End Try
 
    End Sub

IV-D-1. Demande de liaison▲

IV-D-2. InheritanceDemand▲