Privilèges

Des privilèges limitant les processus sont mis en oeuvre dans le noyau et peuvent limiter les processus au niveau des commandes, des utilisateurs, des rôles ou du système.

Commandes d'administration pour la gestion des privilèges

Le tableau suivant répertorie les commandes disponibles pour gérer les privilèges.

Tableau 10-3 Commandes pour la gestion des privilèges

Fichiers disposant d'informations sur les privilèges

Les fichiers suivants contiennent des informations sur les privilèges.

Tableau 10-4 Fichiers contenant des informations sur les privilèges

Privilèges et audit

L'utilisation des privilèges peut être auditée. A chaque fois qu'un processus utilise un privilège, l'utilisation du privilège est enregistrée dans la piste d'audit du jeton d'audit upriv. Lorsque les noms de privilèges font partie de l'enregistrement, leur représentation textuelle est utilisée. Les événements d'audit suivants enregistrent l'utilisation de privilèges :

• AUE_SETPPRIV (événement d'audit) : l'événement génère un enregistrement d'audit lorsqu'un jeu de privilèges est modifié. L'événement d'audit AUE_SETPPRIV se trouve dans la classe pm.

• AUE_MODALLOCPRIV (événement d'audit) : l'événement d'audit génère un enregistrement d'audit lorsqu'un privilège est ajouté depuis l'extérieur du noyau. L'événement d'audit AUE_MODALLOCPRIV se trouve dans la classe ad.

• AUE_MODDEVPLCY (événement d'audit) : l'événement d'audit génère un enregistrement d'audit lorsque la stratégie liée au périphérique est modifiée. L'événement d'audit AUE_MODDEVPLCY se trouve dans la classe ad.

• AUE_PFEXEC audit event : l'événement d'audit génère un enregistrement d'audit lorsqu'un appel est effectué à execve() avec pfexec() activé. L'événement d'audit AUE_PFEXEC se trouve dans les classes d'audit as, ex, ps et ua. Les noms des privilèges sont inclus dans l'enregistrement d'audit.

L'utilisation réussie de privilèges inclus dans le jeu de base n'est pas auditée. La tentative d'utilisation d'un privilège de base qui a été supprimé du jeu de base d'un utilisateur fait l'objet d'un audit.

Prévention de l'escalade de privilèges

Le noyau empêche l'escalade de privilèges. Une escalade de privilèges se produit lorsqu'un privilège permet à un processus de faire plus que ce à quoi il est autorisé. Pour empêcher qu'un processus acquière plus de privilèges que ceux qui lui sont accordés normalement, les modifications de système vulnérable exigent le jeu complet de privilèges. Par exemple, un fichier ou un processus détenu par root (UID=0) ne peut être modifié que par un processus ayant le jeu complet de privilèges. Le compte root n'a pas besoin de privilèges pour modifier un fichier appartenant à root. Toutefois, un utilisateur non root doit avoir tous les privilèges pour modifier un fichier appartenant à root.

De même, les opérations permettant d'accéder aux périphériques requièrent tous les privilèges du jeu effectif.

Les privilèges file_chown_self et proc_owner sont soumis à l'escalade de privilèges. Le privilège file_chown_self permet à un processus d'abandonner ses fichiers. Le privilège proc_owner permet à un processus d'examiner des processus dont il n'est pas propriétaire.

Le privilège file_chown_self est limité par la variable système rstchown. Lorsque la variable rstchown est définie sur zéro, le privilège file_chown_self est supprimé du jeu héritable initial du système et de tous les utilisateurs. Pour plus d'informations sur la variable système rstchown, reportez-vous à la page de manuel chown(1).

Le privilège file_chown_self est attribué, pour des raisons de sécurité, à une commande particulière, placée dans un profil et affectée à un rôle pour l'utiliser dans un shell de profil.

Le privilège proc_owner n'est pas suffisant pour définir un processus UID sur 0. Basculer d'un processus de n'importe quel UID à UID=0 exige tous les privilèges. Etant donné que le privilège proc_owner donne un accès illimité en lecture à tous les fichiers sur le système, le privilège est attribué, pour des raisons de sécurité, à une commande particulière, placée dans un profil et affectée à un rôle pour l'utiliser dans un shell de profil.

---

Attention - Le compte d'un utilisateur peut être modifié afin d'inclure le privilège file_chown_self ou proc_owner dans le jeu héritable initial de l'utilisateur. Vous devez avoir des raisons de sécurité de poids pour placer ces privilèges puissants dans le jeu de privilèges héritable pour n'importe quel utilisateur, rôle ou système.

---

Pour plus de détails sur la manière d'empêcher l'escalade de privilèges pour des périphériques, reportez-vous à la section Privilèges et périphériques.

Anciennes applications et modèle de privilège

Pour s'adapter aux anciennes applications, l'implémentation de privilèges fonctionne à la fois avec le superutilisateur et les modèles de privilège. Le noyau suit automatiquement l'indicateur PRIV_AWARE, qui indique qu'un programme a été conçu pour fonctionner avec des privilèges. Prenons un processus fils qui n'est pas conscient des privilèges. Les privilèges hérités du processus parent sont disponibles dans les jeux effectif et autorisé de l'enfant. Si le processus fils définit un UID sur 0, le processus fils n'a peut-être pas toutes les capacités de superutilisateur. Les jeux effectif et autorisé du processus sont limités aux privilèges dans le jeu limite de l'enfant. Par conséquent, le jeu limite d'un processus conscient des privilèges restreint les privilèges root des processus fils qui ne sont pas conscients des privilèges.