Pourquoi est-il recommandé de créer un groupe et un utilisateur pour certaines applications?

La plupart du temps, lors de l'installation d'un programme à partir de la source, il est recommandé de créer un nouvel utilisateur et un nouveau groupe et de donner /usr/local/<myapp>la propriété de l'utilisateur et du groupe récemment créé.

• 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.

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 devraient 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 (en raison d'un bogue, probablement déclenché par un attaquant), les dommages qu'il peut faire sont limités: seuls les fichiers de données du démon sont affectés (sauf si l'attaquant a réussi à trouver un trou racine local , ce qui peut arriver). Par exemple, le démon de base de données mysqlds'exécute en tant qu'utilisateur et groupe dédié mysql:mysqlet 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 fichiers de données et de configuration statiques qui sont utilisés mais ne doivent pas être modifiés par le démon ne doivent pas appartenir à l'utilisateur dédié; ils devraient appartenir root:root, comme la plupart des fichiers de programme et de configuration. Le mysqldprocessus n'a pas d'écrasement commercial /usr/sbin/mysqldou /etc/mysql/my.cnf, donc ces fichiers ne doivent pas appartenir à l' mysqlutilisateur ou être accessibles en écriture par l' mysqlutilisateur ou le mysqlgroupe. 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-----).

Les root:rootprogrammes qui sont invoqués par un utilisateur mais doivent s'exécuter avec des privilèges supplémentaires constituent une catégorie spéciale d'exécutables qui ne peuvent pas appartenir à . 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, le programme doit être défini comme setgid, de sorte que les privilèges supplémentaires proviennent d'un groupe et non d'un utilisateur. L'exécutable a alors le mode 2755 ( rwxr-sr-x). Les raisons sont doubles:

• L'exécutable ne devrait pas être autorisé à se modifier lui-même, 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écutant 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 de cela). 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).

Ce ne sont pas les applications en général, mais les démons auxquels cela est destiné. La raison en est que le démon peut s'exécuter en tant qu'utilisateur non privilégié au lieu de root, de sorte que s'il présente une vulnérabilité de sécurité et est compromis, les dommages qui peuvent être causés ne sont limités qu'aux zones auxquelles l'utilisateur a accès.

La raison pour laquelle cela est considéré comme une bonne pratique est d'empêcher d'autres utilisateurs du système de remplacer les données et les fichiers de configuration pour l'application particulière.

À titre d'exemple mysql/ mysqlétant le propriétaire du stockage pour les fichiers de base de données MySQL empêche quiconque de ne pas utiliser l'API d'application de corrompre les bases de données. De plus, l'utilisateur mysqln'a généralement pas de véritable shell, donc personne ne peut se connecter en tant qu'utilisateur.

La création d'un nouveau groupe / utilisateur pour un nouveau démon installé améliore la sécurité. Lorsque le processus serveur est exécuté sous un tel utilisateur, il est limité aux droits d'accès de cet utilisateur. En comparaison: quand il est exécuté en tant que root, il peut tout faire.

Cette différence est importante dans le cas où votre démon est mal configuré et / ou contient un bogue lié à la sécurité.

Je ne sais pas ce que vous voulez dire avec la deuxième partie de votre question, c'est-à-dire la partie concernant la /usr/localpropriété. En général, cela n'a pas de sens que le même utilisateur Xsous lequel un démon s'exécute pour des raisons de sécurité possède également le répertoire avec les binaires (car dans ce cas, il pourrait les changer en cas d'exploitation). Mais le répertoire avec les fichiers de données sur lequel le démon travaille devrait être accessible par X- la façon la plus simple de configurer ceci est de devenir Xle propriétaire des répertoires / fichiers de données.

L'exécution d'un démon sous son propre utilisateur spécial n'est qu'une technique de sécurité, d'autres incluent une sorte de «chrootage» ou l'utilisation d'un système de contrôle d'accès obligatoire (MAC) (par exemple SELinux).

Ceci est une considération de sécurité. Il limite les dommages qui peuvent être causés par quelqu'un qui s'introduit dans une application démon. Les applications utilisateur appartiennent généralement à un ID utilisateur standard tel que root.

Si votre serveur Web, votre serveur de messagerie et votre base de données fonctionnent tous comme le même utilisateur, il est plus facile de les compromettre. Si l'un d'eux présente un bogue ou une mauvaise configuration qui autorise l'accès au système, cet accès peut être utilisé pour accéder aux trois applications.

S'ils ont tous des comptes distincts, comme recommandé, seule l'application compromise est susceptible d'être accessible. Bien que les détails de configuration publics de l'autre puissent être lus, il est peu probable que des modifications puissent être apportées.

De nombreux démons permettent aux utilisateurs de télécharger et de télécharger des fichiers et de faire autrement des choses que vous ne voudriez pas qu'ils puissent faire pour les configurations d'autres démons. Si chaque application a son propre ID utilisateur et groupe, il est plus simple de sécuriser les démons.

Le fait d'avoir un groupe spécifique au démon simplifie l'octroi en toute sécurité à un démon d'un accès sécurisé en lecture seule aux fichiers et répertoires. Si le fichier ou le répertoire appartient à un autre utilisateur, mais appartient au groupe des démons, il sera généralement accessible en lecture seule. Les autorisations d'accès peuvent être facilement vérifiées et corrigées avec des outils tels que find.