Ajout de logiciels à Trusted Extensions

Tout logiciel pouvant être ajouté à un système Oracle Solaris peut être ajouté à un système configuré avec Trusted Extensions. En outre, il est possible d'ajouter les programmes utilisant des API Trusted Extensions. L'ajout de logiciels à un système Trusted Extensions est similaire à l'ajout de logiciels à un système Oracle Solaris qui exécute des zones non globales.

Dans Trusted Extensions, les programmes sont généralement installés dans la zone globale pour être utilisés par les utilisateurs standard dans des zones étiquetées. Toutefois, vous pouvez installer les packages dans une zone étiquetée en exécutant la commande pkg dans la zone. Dans ce cas, vous devez vous assurer que la zone peut gérer des comptes d'administration et des invites de mot de passe. Pour plus de détails, reportez-vous à la section Applications non accessibles à une zone étiquetée. Pour plus d'informations sur les packages et les zones, reportez-vous au Chapitre 24, A propos de l’installation automatique et des packages dans un système Oracle Solaris 11.1 comportant des zones installées du manuel Administration d’Oracle Solaris 11.1 : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources.

Sur un site Trusted Extensions, l'administrateur système et l'administrateur de sécurité travaillent ensemble à l'installation des logiciels. L'administrateur de sécurité vérifie que les logiciels ajoutés respectent la stratégie de sécurité. Lorsqu'un logiciel requiert des privilèges ou des autorisations pour fonctionner, il affecte un profil de droits approprié aux utilisateurs du logiciel.

L'importation d'un logiciel à partir d'un média amovible nécessite une autorisation. Un compte avec l'autorisation Allouer un périphérique peut importer ou exporter des données à partir d'un média amovible. Les données peuvent inclure du code exécutable. Un utilisateur standard ne peut importer que des données sous une étiquette comprise dans son autorisation.

L'administrateur système est chargé d'ajouter les programmes approuvés par l'administrateur de sécurité.

Mécanismes de sécurité pour le logiciel Oracle Solaris

Trusted Extensions utilise les mêmes mécanismes de sécurité qu'Oracle Solaris. Il s'agit notamment des mécanismes suivants :

• Autorisations : une autorisation peut être nécessaire pour permettre l'utilisation d'un programme. Pour plus d'informations sur les autorisations, reportez-vous à la section Eléments et concepts de base RBAC du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité. Reportez-vous également à la page de manuel auth_attr(4) man page.

• Privilèges : des privilèges peuvent être assignés à des programmes et des processus. Pour plus d'informations sur les privilèges, reportez-vous au Chapitre 8, Utilisation des rôles et des privilèges (présentation) du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité. Reportez-vous également à la page de manuel privileges(5).

  La commande ppriv fournit un utilitaire de débogage. Pour plus d'informations, reportez-vous à la page de manuel ppriv(1). Pour obtenir des instructions sur l'utilisation de cet utilitaire avec des programmes qui fonctionnent dans des zones non globales, reportez-vous à la section Utilisation de l’utilitaire ppriv du manuel Administration d’Oracle Solaris 11.1 : Oracle Solaris Zones, Oracle Solaris 10 Zones et gestion des ressources.

• Profils de droits : les profils de droits rassemblent les attributs de sécurité à affecter à des utilisateurs ou à des rôles en un point unique. Pour plus d'informations sur les profils de droits, reportez-vous à la section Profils de droits RBAC du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.

• Bibliothèques de confiance : les bibliothèques partagées dynamiquement et utilisées par setuid, setgid et les programmes privilégiés peuvent uniquement être chargés à partir de répertoires de confiance. Comme dans Oracle Solaris, la commande crle est utilisée pour ajouter les répertoires de bibliothèque partagés d'un programme exécuté avec des privilèges à la liste de répertoires de confiance. Pour plus d'informations, reportez-vous à la page de manuel crle(1).

Evaluation de la sécurité d'un logiciel

Lorsque des privilèges ont été assignés à un logiciel ou lorsque ce dernier s'exécute à l'aide d'un autre ID d'utilisateur ou ID de groupe, le logiciel devient de confiance. Ce type de logiciel peut contourner certains aspects de la stratégie de sécurité de Trusted Extensions. Gardez à l'esprit qu'un logiciel peut être de confiance bien qu'il puisse ne pas être digne de confiance. Pour accorder des privilèges à un logiciel, l'administrateur de sécurité doit attendre qu'un examen minutieux ait révélé que le logiciel utilise les privilèges de manière fiable.

Les programmes d'un système de confiance se répartissent en trois catégories :

• Les programmes qui n'exigent aucun attribut de sécurité : certains programmes s'exécutent à un seul niveau et ne nécessitent aucun privilège. Ces programmes peuvent être installés dans un répertoire public tel que /usr/local. Pour y accéder, assignez les programmes sous forme de commandes dans les profils de droits des utilisateurs et des rôles.

• Les programmes qui s'exécutent en tant que root : certains programmes s'exécutent avec setuid 0. Un ID d'utilisateur effectif de 0 peut être affecté à de tels programmes dans un profil de droits. L'administrateur de sécurité affecte ensuite le profil à un rôle d'administration.

  ---

  Astuce - Si l'application est capable d'utiliser les privilèges de manière fiable, affectez les privilèges nécessaires à l'application et n'exécutez pas le programme en tant que root.

  ---

• Les programmes qui requièrent des privilèges : certains programmes peuvent nécessiter des privilèges pour des motifs qui ne sont pas évidents. Même si un programme ne semble pas exécuter de fonction contrevenant à la stratégie de sécurité du système, il peut être en train d'effectuer en interne une opération qui ne respecte pas la sécurité. Par exemple, le programme peut utiliser un fichier journal partagé, ou peut lire dans /dev/kmem. Pour les questions de sécurité, reportez-vous à la page de manuel mem(7D).

  Parfois, ignorer une stratégie interne n'a pas d'incidence particulière sur le fonctionnement de l'application. Au contraire, il peut en résulter un bénéfice pour les utilisateurs.

  Si votre organisation a accès au code source, vérifiez si vous pouvez supprimer les opérations pouvant outrepasser les stratégies de sécurité sans affecter les performances de l'application.

Responsabilités du développeur lors de la création des programmes de confiance

Bien que le développeur d'un programme puisse manipuler des jeux de privilèges dans le code source, si l'administrateur de sécurité n'attribue pas les privilèges requis au programme, le programme échoue. Le développeur et l'administrateur de sécurité doivent coopérer lors de la création des programmes de confiance.

Un développeur qui écrit un programme de confiance doit effectuer les opérations suivantes :

1. Comprendre où le programme requiert des privilèges pour pouvoir mener à bien sa mission.

2. Connaître et mettre en oeuvre des techniques telles que la séparation des privilèges pour pouvoir utiliser les privilèges en toute sécurité dans les programmes.

3. Etre conscient des implications en matière de sécurité lorsqu'il affecte des privilèges à un programme. Le programme doit respecter la stratégie de sécurité.

4. Compiler le programme en utilisant des bibliothèques partagées liées au programme à partir d'un répertoire de confiance.

   Pour plus d'informations, reportez-vous au Developer’s Guide to Oracle Solaris 11 Security. Pour voir des exemples de code pour Trusted Extensions, reportez-vous au manuel Trusted Extensions Developer’s Guide.

Responsabilités de l'administrateur de sécurité pour les programmes de confiance

L'administrateur de sécurité est responsable du test et de l'évaluation des nouveaux logiciels. Une fois le logiciel considéré comme digne de confiance, l'administrateur de sécurité configure des profils de droits et tout autre attribut relatif à la sécurité pour le programme.

Les responsabilités suivantes lui incombent alors :

1. S'assurer que le programmeur et le processus de distribution de programmes sont de confiance.

2. Déterminer les privilèges requis par le programme de l'une des manières suivantes :

   • En demandant au programmeur.

   • En recherchant les privilèges que le programme s'attend à utiliser dans le code source.

   • En recherchant dans le code source les autorisations que le programme exige de ses utilisateurs.

   • En utilisant les options de débogage de la commande ppriv afin de détecter l'utilisation de privilèges. Pour consulter des exemples, reportez-vous à la page de manuel ppriv(1).

3. Examiner le code source pour s'assurer que son comportement est fiable par rapport aux privilèges dont le programme a besoin pour fonctionner.

   Si ce n'est pas le cas et vous avez la possibilité de modifier le code source du programme, modifiez ce code. Un consultant en sécurité ou un développeur possédant des connaissances dans ce domaine peuvent s'en charger. Les modifications peuvent inclure la séparation des privilèges ou la recherche d'autorisations.

   L'assignation de privilèges doit être effectuée manuellement. Un programme qui échoue en raison d'un manque de privilèges peut s'en voir assigner de nouveaux. L'administrateur de sécurité peut également décider d'assigner un ID d'utilisateur ou un ID de groupe pour rendre le privilège non nécessaire.