> Tech > L’autorité adoptée exige quelques précautions

L’autorité adoptée exige quelques précautions

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

On l’a compris, l’autorité adoptée est très efficace pour accorder aux utilisateurs l’accès temporaire aux données. Mais il faut la manier avec prudence car elle pourrait bien affaiblir le système de sécurité au lieu de le renforcer. L’autorité adoptée a pour mérite de permettre aux utilisateurs d’accéder aux objets qui

leur seraient normalement interdits. Mais cet avantage est également son inconvénient !

Revenons à l’exemple de la figure 2 : si l’on n’y prend garde, on pourrait permettre à l’autorité de QSECOFR de se propager au programme CMD_LINE. Le meilleur choix de programmation en figure 2 consiste à appeler PGM_B, à effectuer la fonction qui a besoin de QSECOFR, puis de revenir à PGM_A.

Une autre précaution consiste à qualifier chaque instruction CALL avec un nom de bibliothèque (par exemple, CALL MYLIBRARY/MYPROGRAM). Quand vous qualifiez le nom du programme avec la bibliothèque contenant le programme, vous neutralisez le comportement par défaut qui permet à i5/OS de résoudre l’objet programme en se basant sur le chemin de recherche de la liste de bibliothèques (*LIBL). Je sais bien que cette façon de faire est plutôt rare dans le monde de la programmation, mais le fait de spécifier la bibliothèque vous donne l’assurance d’appeler le programme visé et pas un cheval de Troie inséré dans une bibliothèque placée plus haut dans la liste.

Terminons par deux pièges liés à l’autorité adoptée. En premier lieu, du fait qu’elle est basée sur une pile, elle disparaît quand une nouvelle pile est établie : c’est ce qui se produit quand un job est soumis à un traitement batch. À titre d’exemple, supposons que le programme initial d’une application adopte l’autorité et affiche le menu de l’application. Quand une option du menu est choisie en vue de soumettre un job au traitement batch, le programme appelé sur la soumission batch doit lui aussi être configuré pour adopter l’autorité. Un autre inconvénient de l’autorité adoptée est qu’elle est totalement ignorée quand on accède aux objets dans l’IFS. Autrement dit, si un objet répertoire est réglé sur *PUBLIC DTAAUT(*EXCLUDE) et OBJAUT(*NONE), et si vous voulez accéder à un fichier stream dans le répertoire, vous ne pouvez pas obtenir le droit d’accéder au répertoire par l’intermédiaire de l’autorité adoptée. Cette réalité m’amène à vous exposer l’une des autres techniques pour donner à des utilisateurs l’accès temporaire aux objets.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010