Ignorer les liens de navigation | |
Quitter l'aperu | |
Transition d'Oracle Solaris 10 vers Oracle Solaris 11 Oracle Solaris 11 Information Library (Français) |
1. Transition d'Oracle Solaris 10 vers Oracle Solaris 11 (présentation)
2. Transition vers une méthode d'installation d'Oracle Solaris 11
4. Gestion des fonctions de stockage
5. Gestion des systèmes de fichiers
7. Gestion de la configuration réseau
8. Gestion de la configuration système
Modifications apportées aux fonctions de sécurité
Fonctions de sécurité supprimées
Modifications apportées à la sécurité des fichiers et systèmes de fichiers
Réintroduction de la propriété aclmode
Chiffrement des systèmes de fichiers ZFS
10. Gestion des versions d'Oracle Solaris dans un environnement virtuel
11. Modifications apportées à l'environnement et à la gestion des comptes utilisateur
12. Utilisation des fonctionnalités de bureau d'Oracle Solaris
A. Transition de versions antérieures vers Oracle Solaris 11
Les informations suivantes décrivent le fonctionnement des rôles, droits et privilèges sous Oracle Solaris 11 :
Attribution ou délégation d'autorisations : Oracle Solaris fournit des autorisations pour déléguer des droits administratifs spécifiques à certains utilisateurs et rôles, afin de mettre en oeuvre une séparation des tâches. Sous Oracle Solaris 10, les autorisations se terminant par .grant sont requises pour déléguer une autorisation à un autre utilisateur. Sous Oracle Solaris 11, deux nouveaux suffixes sont utilisés : .assign et .delegate. Par exemple : solaris.profile.assign et solaris.profile.delegate. Le premier suffixe accorde le droit de déléguer tout profil de droits à tout utilisateur ou rôle. Le second suffixe est plus restrictif, car seuls les profils de droits déjà assignés à l'utilisateur actuel peuvent être délégués. Comme solaris.* est assigné au rôle root, ce rôle peut assigner toute autorisation à tout utilisateur ou rôle. Par mesure de sécurité, aucune autorisation se terminant par .assign n'est incluse dans un profil par défaut.
Profil de droits Media Restore (restauration des médias) : ce profil de droits et cet ensemble d'autorisations permettent d'escalader les privilèges d'un compte sans rôle root. Ce profil existe, mais il ne fait partie d'aucun autre profil de droits. Comme ce profil de droits Media Restore permet d'accéder à l'ensemble du système de fichiers racine, son utilisation peut escalader des privilèges. Des fichiers délibérément modifiés ou des médias de substitution peuvent être restaurés. Par défaut, le rôle root inclut ce profil de droits.
Suppression du profil Primary Administrator (administrateur principal) : l'utilisateur initial créé lors de l'installation reçoit les rôles et droits suivants :
Rôle root
Profil de droits System Administrator (administrateur système)
Accès à la commande sudo pour toutes les commandes exécutées en tant que root
Authentification des rôles : vous pouvez spécifier user ou role pour le mot-clé roleauth. Reportez-vous à la page de manuel user_attr(4).
Root en tant que rôle : root est désormais un rôle par défaut, donc non anonyme, et qui ne peut pas se connecter à distance à un système. Pour plus d'informations sur la transformation du rôle root en utilisateur, reportez-vous à la section Procédure de modification du rôle root en utilisateur du manuel Administration d’Oracle Solaris : services de sécurité.
Privilèges de base d'Oracle Solaris 11 (entre autres) :
file_read
file_write
net_access
Versions de shells de profils pour les shells standard : chaque shell standard dispose désormais de sa propre version de profil. Les shells de profils suivants sont disponibles :
pfbash
pfcsh
pfksh
pfksh93
pfrksh93
pfsh
pftcsh
pfzsh
Reportez-vous à la page de manuel pfexec(1).
Profils de droits : les bases de données user_attr, prof_attr et exec_attr sont désormais en lecture seule. Ces bases de données de fichiers locaux sont assemblées à partir de fragments se trouvant dans /etc/user_attr.d, /etc/security/prof_attr.d et /etc/security/exec_attr.d. Les fragments de fichiers ne sont pas fusionnés en une seule version du fichier, ils restent sous forme de fragments. Cette modification permet aux packages de fournir des profils RBAC (Role Based Access Control, contrôle d'accès basé sur les rôles) complets ou partiels. Les entrées ajoutées au référentiel de fichiers locaux à l'aide des commandes useradd et profiles sont ajoutées au fichier local-entries du répertoire de fragments. Pour ajouter ou modifier un profil, exécutez la commande profiles. Reportez-vous à la section Procédure de création ou de modification d’un profil de droits du manuel Administration d’Oracle Solaris : services de sécurité.
Profil d'arrêt de droits : ce profil permet aux administrateurs de créer des comptes limités. Reportez-vous à la section Profils de droits RBAC du manuel Administration d’Oracle Solaris : services de sécurité.
Commande pfsh script : cette commande fonctionne désormais comme la commande pfsh -c script. Auparavant, les commandes d'un script ne pouvaient pas tirer parti de la fonctionnalité RBAC, sauf si la première ligne du script spécifiait un shell de profil. Si vous souhaitiez utiliser la fonctionnalité RBAC, vous deviez modifier les scripts ; cela est désormais inutile, car le programme appelant du script (ou un ancêtre au sein d'une session) peut spécifier un shell de profil.
Commande pfexec : cette commande n'est plus setuid root. Le nouvel attribut de processus PF_PFEXEC est défini lorsque la commande pfexec ou un shell de profil sont exécutés. Ensuite, le noyau définit les privilèges appropriés sur exec. Cette implémentation assure que les sous-shells sont habilités ou limités, selon le cas.
Lorsque le noyau traite une commande exec(2), il traite setuid to root différemment. Notez que toute commande setgid ou setuid pour un autre uid que root fonctionne comme auparavant. Le noyau recherche désormais une entrée dans le profil RBAC Forced Privilege dans exec_attr(4) pour déterminer les privilèges sous lesquels le programme doit s'exécuter. Au lieu de démarrer avec l'uid root et tous les privilèges, le programme s'exécute avec l'uid actuel et uniquement les privilèges supplémentaires que le profil d'exécution RBAC Forced Privilege a assignés à ce nom de chemin.
Lorsque des privilèges sont assignés directement à un utilisateur, ces privilèges sont en fait présents dans chaque shell. Lorsque les privilèges ne lui sont pas directement attribués, l'utilisateur doit ouvrir un shell de profil. Par exemple, lorsque les commandes ayant des privilèges attribués se trouvent dans un profil de droits répertorié dans la liste de profils de droits de l'utilisateur, l'utilisateur doit exécuter la commande dans un shell de profil.
Pour afficher des privilèges en ligne, reportez-vous à la page de manuel privileges(5). Le format de privilège qui s'affiche est utilisé par les développeurs.
$ man privileges Standards, Environments, and Macros privileges(5) NAME privileges - process privilege model ... The defined privileges are: PRIV_CONTRACT_EVENT Allow a process to request reliable delivery of events to an event endpoint. Allow a process to include events in the critical event set term of a template which could be generated in volume by the user. ...
Exemple 9-1 Affichage de privilèges assignés directement
Si des privilèges vous ont été attribués directement, votre jeu de base contient plus que le jeu de base par défaut. Dans l'exemple suivant, l'utilisateur a toujours accès au privilège proc_clock_highres.
$ /usr/bin/whoami jdoe $ ppriv -v $$ 1800: pfksh flags = <none> E: file_link_any,…,proc_clock_highres,proc_session I: file_link_any,…,proc_clock_highres,proc_session P: file_link_any,…,proc_clock_highres,proc_session L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time $ ppriv -vl proc_clock_highres Allows a process to use high resolution timers.