Sécurité System i - Profils de groupe *SECADM *ALLOBJ

16/06/2013
Sur de nombreux sites on rencontre des erreurs fondamentales en matière d'accord de droit. Certaines erreurs sont parfois très difficiles à corriger

Profil de groupe:


Des conseillers mal avertis vous indiquent de donner les droits *ALLOBJ au profil de groupe des utilisateurs d'une application. C'est probablement la plus grave faute de sécurité qui peut être commise sur IBM-i. Vous donnez ainsi les clefs de la machine à vos utilisateurs, qui peuvent, intentionnellement ou non mettre en péril les données de l'entreprise, divulguer des informations confidentielles ou détruire le système d'exploitation.

Certains profils de groupe fournis pas IBM-i sont dangereux car mal nommer. Le pire est le profil QPGMR.

QPGMR


Le profil de groupe QPGMR dispose des droits spéciaux *ALLOBJ.

Un profil hérite des droits de son profile de groupe. Donner le profile de groupe QPGMR revient donner les clefs de la machine.
Le profil QPGMR est utilisé pour le démarrage du système, c'est ce profil qui exécute le programme de démarrage QSTRUP. On ne peut donc pas lui retirer les droits *ALLOBJ.
D'une manière générale aucun utilisateur ne doit disposer d'un des profils fournis par le système comme profil de groupe.
Notamment : QGRPPRF, QHOD, QLPAUTO, QLPINSTALL, QPGMR, QSECOFR, QSYS, QTIVROOT, QUSER. . .

Classe d'utilisateur


La classe d'utilisateur défini les droits spéciaux qui sont accordés aux utilisateurs.
Selon le niveau de sécurité, les droits accordés sont plus ou moins restrictifs.

Droits spéciaux


*ALLOBJ

Les droits spéciaux *ALLOBJ doivent être distribués avec beaucoup de précautions. Avec les droits *ALLOBJ un utilisateur dispose des clefs de la machine.
Il peut soumettre un travail sous le profil de n'importe quel autre utilisateur, par exemple un utilisateur *SECADM.

Un utilisateur USRALLO de classe *USER n'a normalement aucun droit spécial.
Si on lui accorde le droit spécial *ALLOBJ et qu'il entre la commande:

Option ou commande
===> CHGUSRPRF USRPRF(usrallo) SPCAUT(*ALLOBJ *AUDIT *IOSYSCFG *JOBCTL
*SAVSYS *SECADM *SERVICE *SPLCTL) .

F3=Exit F4=Invite F9=Rappel F12=Annuler F13=Informations techniques
F23=Définir menu initial

*SECADM obligatoire pour créer ou modifier des profils utilisateur.

Il reçoit le message CPF2292 *SECADM obligatoire pour créer ou modifier des profils utilisateur.
---------------------------
Il soumet la même commande sous un profil *SECOFR *SECADM.

Option ou commande
===> SBMJOB CMD(CHGUSRPRF USRPRF(USRALLO) SPCAUT(*ALLOBJ *AUDIT *IOSYSCFG
*JOBCTL *SAVSYS *SECADM *SERVICE *SPLCTL)) USER(USRSECOFR)

F3=Exit F4=Invite F9=Rappel F12=Annuler F13=Informations techniques
F23=Définir menu initial

Travail 133691/USRSECOFR/QDFTJOBD soumis à la file d'attente SABTH de BKUPER.

Le travail par lot est exécuté avec le profil USRSECOFR et la commande CHGUSRPRF est exécutée avec succès. Voici notre utilisateur USRALLO avec tous les droits spéciaux du système, il peut maintenant faire tout ce qu'il veut : corrompre les données, lancer un IPL, voler des informations confidentielles...

*SECADM

Une idée reçue est que les profils avec les droits *SECADM ont tous les droits.
C'est faut. Un utilisateur *SECADM
ne peut pas accorder de droits supérieurs à ceux qu'il possède lui-même. S'il n'a pas les droits sur un objet il ne peut pas accordé de droit sur cet objet à un de ses utilisateurs. Il ne peut pas accorder le droit *SECADM.
D'autre part il ne voit que les utilisateurs qu'il a créés ou pour lesquels un autres *SECADM lui a donné le droit de modification.
On peut ainsi avoir plusieurs administrateurs de sécurité qui ont chacun leur propres utilisateurs dans leur domaine de compétence.
Par exemple :
Un administrateur de l'application stocks et un administrateur de l'application paye.
Si l'administrateur de l'application stock est exclu de l'application paye il ne pourra pas accéder à la paye et ne pourra pas accorder des droits sur la paye à un autre utilisateur, il ne pourra pas gérer des utilisateurs de l'application paye si on ne lui a pas accordé de droit sur ces utilisateurs.
Même s'il à les droits sur un profil utilisateur de la paye, il ne pourra pas modifier les droits de cet utilisateur sur les objets de la paye.
Pour qu'un administrateur sécurité puisse créer un utilisateur il faut :
  • Qu'il ai les droits *ADD sur son profil, ou lui donner la propriété de son profil.
  • Qu'il ai les droits d'exécution sur le répertoire '/home' pour le paramètre HOMEDIR.