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.
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.
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 :
Comprendre où le programme requiert des privilèges pour pouvoir mener à bien sa mission.
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.
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é.
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 .
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 :
S'assurer que le programmeur et le processus de distribution de programmes sont de confiance.
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). Vous pouvez également utiliser dtrace pour évaluer les attributions de privilèges et d'utilisation.
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.
Créer et affecter des profils de droits pour le nouveau programme.