La plupart du temps, lors de l'installation d'un programme à partir des sources, il est recommandé de créer un nouvel utilisateur et un nouveau groupe et de donner /usr/local/<myapp> l'utilisateur et la propriété du groupe récemment créés.
-
Pourquoi une telle pratique est-elle considérée comme une bonne pratique ?
-
Qu'est-ce que cela améliore ?
Exemple :utilisateur mysql/groupe mysql pour le serveur de base de données MySQL.
Réponse acceptée :
La pratique n'est pas de créer un utilisateur et un groupe par application, mais par service. Autrement dit, les programmes exécutés par un utilisateur local n'ont pas besoin d'être installés en tant qu'utilisateur autre que root. Ce sont des démons, des programmes qui s'exécutent en arrière-plan et qui exécutent des requêtes provenant du réseau ou d'autres moyens de communication, qui doivent s'exécuter en tant qu'utilisateur dédié.
Le démon s'exécute en tant qu'utilisateur dédié, de sorte que s'il se comporte mal (à cause d'un bogue, probablement déclenché par un attaquant), les dégâts qu'il peut causer sont limités :seuls les fichiers de données du démon sont affectés (à moins que l'attaquant n'ait réussi à trouver un trou racine local , ce qui peut arriver). Par exemple, le démon de base de données mysqld s'exécute en tant qu'utilisateur et groupe dédiés mysql:mysql et les fichiers de données de la base de données (/var/lib/mysql/* ) appartiennent à mysql:mysql .
Notez que l'exécutable du démon et les autres données statiques et fichiers de configuration qui sont utilisés mais ne doivent pas être modifiés par le démon ne doivent pas appartenir à l'utilisateur dédié ; ils doivent appartenir à root:root , comme la plupart des fichiers de programme et de configuration. Le mysqld le processus n'a rien à faire en écrasant /usr/sbin/mysqld ou /etc/mysql/my.cnf , donc ces fichiers ne doivent pas appartenir au mysql utilisateur ou être accessible en écriture par le mysql utilisateur ou le mysql grouper. Si certains fichiers doivent être lisibles uniquement par le démon et l'administrateur, ils doivent appartenir à l'utilisateur root et au groupe dédié, et avoir le mode 0640 (rw-r----- ).
Une catégorie spéciale d'exécutables qui ne peuvent pas appartenir à root:root sont des programmes qui sont invoqués par un utilisateur mais qui doivent être exécutés avec des privilèges supplémentaires. Ces exécutables doivent être setuid root s'ils doivent s'exécuter (au moins en partie) en tant que root; alors l'exécutable doit avoir le mode 4755 (rwsr-xr-x ). Si le programme a besoin de privilèges supplémentaires mais pas en tant que root, alors le programme doit être mis en setgid, de sorte que les privilèges supplémentaires passent par un groupe et non par un utilisateur. L'exécutable est alors en mode 2755 (rwxr-sr-x ). Les raisons sont doubles :
- L'exécutable ne doit pas être autorisé à se modifier, de sorte que si un utilisateur parvient à exploiter une vulnérabilité, il pourrait être en mesure de modifier les fichiers de données utilisés par le programme mais pas d'injecter un cheval de Troie dans l'exécutable pour attaquer d'autres utilisateurs exécuter le programme.
- Le fichier de données de l'exécutable appartient au groupe. Un programme setuid devrait basculer entre l'utilisateur réel (l'utilisateur qui a appelé le programme) pour interagir avec l'utilisateur et avec l'utilisateur effectif (l'utilisateur sous lequel le programme s'exécute) pour accéder à ses fichiers de données privés (la raison en est avoir des privilèges supplémentaires). Un programme setgid peut en outre séparer les données par utilisateur qui ne sont accessibles qu'au groupe (par exemple, en stockant les fichiers appartenant à l'utilisateur dans un répertoire accessible uniquement à root et au groupe du programme).