> Tech > Empêcher que l’autorité adoptée ne se propage

Empêcher que l’autorité adoptée ne se propage

Tech - Par Collectif - Publié le 24 juin 2010
email

Cette semaine, une boîte à outils portant sur le développement d'applications et l'utilisation des propriétés dans dans l'environnement i notamment. 

Un dossier spécial développeur avec cette boîte à outils. Au programme, la construction d'une commande CL SCAN, l'utilisation de Free Format, la date du job et de la date du système, les serveurs hôtes, la propriété d’un objet..

Empêcher que l’autorité adoptée ne se propage

L’autorité adoptée est une méthode puissante pour augmenter temporairement l’autorité d’un job, afin qu’il puisse accéder à des objets ou à des données auxquels l’utilisateur n’a normalement pas accès. L’autorité adoptée est toujours basée sur un objet programme et sur la propriété du programme.

Et elle n’est reconnue que dans le système de fichiers QSYS.LIB. En général, un programme peut adopter l’autorité depuis une source autre que le profil utilisateur actuellement actif, de l’une des deux manières suivantes :

  1. L’objet programme peut avoir l’attribut USRPRF réglé sur une valeur de *USER ou *OWNER: *USER signifie que l’autorité à l’exécution n’est vérifiée que pour le profil utilisateur qui exécute actuellement le job ; *OWNER signifie que si le profil utilisateur qui exécute actuellement le job n’a pas suffisamment d’autorité pour une certaine action, l’autorité du profil utilisateur possédant le programme servira à consulter l’autorité.
  2. Si un programme n’a pas l’attribut USRPRF réglé sur *OWNER, il peut hériter de l’autorité adoptée de la part d’un programme placé plus haut dans la pile d’invocation, mais seulement si l’attribut de l’autorité adoptée Use (USEADPAUT) du programme courant a été réglé sur *YES.

Le seul moyen de faire cela passe par l’utilisation de la commande CHGPMG. USEADPAUT est réglé sur *NO à la première création du programme. Vous pouvez utiliser la valeur système QUSEADPAUT pour spécifier une liste d’autorisations à contrôler qui est autorisée à changer un programme en USEADPAUT(*YES).

Bien que l’autorité adoptée soit utile pour obtenir une autorité adéquate pour des activités spécifiques et pertinentes, il faut l’utiliser avec prudence. En effet, si une autorité adoptante de programme provenant d’un profil utilisateur puissant appelle un autre programme ou commande, lequel à son tour met une ligne de commande à la disposition de l’utilisateur, celui-ci pourra exécuter des commandes sous l’autorité adoptée du puissant utilisateur.

Malheureusement, il n’existe aucun attribut de programme pour contrôler si l’autorité adoptée au niveau d’invocation courant devrait être disponible pour que le prochain niveau d’invocation puisse l’utiliser – c’est ce qu’on appelle aussi la propagation d’autorité. L’attribut d’autorité d’invocation Modify intégrée à ILE MI (‘_MODINVAU’) est, cependant, disponible pour tous les compilateurs ILE, et cette fonction intégrée peut définir l’attribut de propagation d’autorité pour l’invocation courante d’un programme, sans affecter de manière permanente l’objet programme. J’ai écrit un petit programme de test pour démontrer comment la fonction MODINVAU affecte l’autorité adoptée propagée.

Veuillez compiler et changer le programme CBX605, en suivant soigneusement les instructions de l’en-tête source. Cette situation requiert l’accès au profil utilisateur QSECOFR. Voici la séquence d’événements qui se déroule quand vous appelez le programme de test :

  1.  La fonction MODINVAU bloque la propagation de l’autorité adoptée, et QCMD est appelé.
  2. L’exécution de la commande WRKUSRPRF *ALL n’affiche que les profils utilisateurs sur lesquels le profil utilisateur exécutant a une autorité. Appuyez sur F3 pour continuer.
  3. La fonction MODINVAU réinstaure la propagation de l’autorité adoptée et QCMD est appelée.
  4. Une nouvelle exécution de la commande WRKUSRPRF *ALL vous montrera maintenant tous les profils utilisateurs, indépendamment de l’autorité que le profil utilisateur exécutant a sur les profils utilisateurs listés.

Appuyez sur F3 pour mettre fin au programme de test. Pour que ce test fonctionne, le profil exécutant le programme de test doit avoir LMTCPB(*NO). L’autorité adoptée ne remplace pas cet attribut du profil utilisateur. Et si vous avez des programmes ILE qui adoptent l’autorité et restent dans la pile de programmes, propageant par conséquent et par mégarde l’autorité adoptée à d’autres programmes, vous pouvez copier la fonction MODINVAU utilisée dans le programme de test ci-dessus pour éliminer ce risque.

La fonction intégrée _MODINVAU est documentée à cette adresse.

– Carsten Flensburg

Téléchargez cette ressource

Comment sécuriser une PME avec l’approche par les risques ?

Comment sécuriser une PME avec l’approche par les risques ?

Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.

Tech - Par Collectif - Publié le 24 juin 2010