Quelle est la différence entre l'utilisateur et le compte de service?

Question

Je voudrais connaître la différence entre l'utilisateur et le compte de service.

Je sais que par ex. Jenkins installé sur ubuntu n'est pas un utilisateur, mais un compte de service .

1. Quelle est l'utilisation du compte de service?
2. Quand en avons-nous besoin?
3. Comment puis-je créer un compte de service?

Answer 1

Les comptes d'utilisateur sont utilisés par de vrais utilisateurs, les comptes de service sont utilisés par les services système tels que les serveurs Web, les agents de transport de courrier, les bases de données, etc. Par convention, et uniquement par convention, les comptes de service ont des ID utilisateur dans la plage inférieure, par ex. <1000 environ. À l'exception de l'UID 0, les comptes de service ne disposent d'aucun privilège spécial. Les comptes de service peuvent posséder - et possèdent généralement - des ressources spécifiques, même des fichiers spéciaux de périphérique, mais ils ne disposent pas de privilèges de type superutilisateur.

Les comptes de service peuvent être créés comme des comptes d'utilisateurs ordinaires (par exemple en utilisant useradd). Cependant, les comptes de service sont généralement créés et configurés par le gestionnaire de packages lors de l'installation du logiciel de service. Ainsi, même en tant qu'administrateur, vous devez rarement être directement concerné par la création de comptes de service.

Pour une bonne raison: contrairement aux comptes d'utilisateurs, les comptes de service n'ont souvent pas de shell de connexion "approprié", c'est-à-dire qu'ils ont /usr/sbin/nologin Comme shell de connexion (ou, dans le passé, /bin/false). De plus, les comptes de service sont généralement verrouillés, c'est-à-dire qu'il n'est pas possible de se connecter (pour les /etc/passwd Et /etc/shadow Traditionnels, cela peut être obtenu en définissant le hachage du mot de passe sur des valeurs arbitraires telles que * ou x). Il s'agit de durcir les comptes de service contre les abus ( défense en profondeur ).

Avoir des comptes de service individuels pour chaque service sert deux objectifs principaux: C'est une mesure de sécurité pour réduire l'impact en cas d'incident avec un service ( compartimentation ) et simplifie l'administration, car il devient plus facile de déterminer quelles ressources appartiennent à quel service. Voir ce ou ce réponses aux questions connexes pour plus de détails.

Answer 2

À l'origine, les utilisateurs devaient correspondre à un humain utilisant le système, d'où le nom. Chaque processus s'exécute en tant qu'utilisateur particulier et chaque fichier appartient à un utilisateur particulier. Un utilisateur spécial, appelé root, est utilisé pour les choses qui n'appartiennent à aucun utilisateur humain particulier, c'est-à-dire le système d'exploitation lui-même. Étant donné que root correspond au système d'exploitation lui-même, il dispose de tous les privilèges.

Bientôt, les gens ont trouvé qu'il était pratique de créer plusieurs utilisateurs du système, sans privilèges étendus. Cela permet d'isoler les différents services qui s'exécutent sur une machine, afin qu'ils ne marchent pas les uns sur les autres. Un compte de service (ou "compte système", ces deux termes sont synonymes) est celui qui correspond à un service exécuté sur le système, plutôt qu'à une personne utilisant le système. Vous avez généralement un compte de service pour chaque tâche exécutée sur le système qui possède son propre ensemble de privilèges (par exemple ses propres fichiers, ses propres ports réseau, etc.).

Il n'y a pas de définition formelle du compte humain vs système/service. Le noyau s'en fiche (à part l'octroi de nombreux privilèges à l'utilisateur avec l'UID 0). La plupart des commandes d'administration ne se soucient pas non plus. Certaines différences typiques sont:

• Un utilisateur humain a un vrai nom comme "John Doe", tandis qu'un utilisateur système a un nom descriptif comme "démon nasal" ou aucun.
• Un utilisateur humain possède un véritable Shell de connexion (par exemple /bin/sh Ou /bin/bash Ou /bin/csh. Certains utilisateurs du système ont un Shell (presque toujours /bin/sh), D'autres ne le font pas. 't, selon la façon dont ils sont destinés à être utilisés (par exemple su foo nécessite que foo ait un Shell).
• Un utilisateur humain a souvent un mot de passe - mais ce n'est pas toujours le cas, par exemple, un utilisateur distant uniquement peut ne disposer que d'une clé SSH. Notez que sur les unités modernes, le mot de passe n'est pas dans /etc/passwd Mais dans un autre fichier tel que /etc/shadow.
• Le répertoire de base d'un utilisateur humain est généralement sous /home (Ou un emplacement spécifique au site), tandis que le répertoire de base d'un utilisateur système n'est généralement pas sous /home Et peut ne pas exister (mais il existe des exceptions).
• La plupart des sites désignent une plage d'ID utilisateur pour les utilisateurs du système et une plage disjointe pour les utilisateurs humains. La réservation de 100–65533 ou 500–65533 ou 1000–65533 est typique, et la plupart des distributions sont configurées pour commencer à allouer des ID utilisateur réels à partir de 500 ou 1000.

Sur les sites où les comptes sont partagés sur plusieurs machines, il existe généralement un serveur central contenant des listes d'utilisateurs, accessible via NIS ou LDAP . L'entrée passwd dans /etc/nsswitch.conf spécifie où trouver les informations utilisateur. Il est courant d'avoir des utilisateurs système dans la base de données locale /etc/passwd Et de vrais utilisateurs de la base de données à l'échelle du réseau, mais parfois il y a des utilisateurs système dans la base de données à l'échelle du réseau (pour appliquer des UID cohérents, ce qui facilite la réplication du serveur et des données ), et il y a parfois des utilisateurs humains dans le fichier local (pour les laisser se connecter même lorsque le réseau est arrosé).

Un compte accessible à l'homme déguisé en utilisateur système n'aurait généralement pas de vrai nom, mais aurait un shell de connexion, et soit un mot de passe, soit une clé SSH, tout en ayant un ID utilisateur dans la plage système. En fait, ce serait un meilleur déguisement d'utiliser un compte système réel dont la suppression entraînerait l'arrêt de certains services. Mais vous ne pouvez pas avoir de règles strictes pour détecter les attaques potentielles: par définition, les attaquants ne suivent pas les règles.

Les comptes de service et les comptes humains sont gérés par les mêmes commandes et enregistrés dans les mêmes fichiers. Les commandes de création de compte peuvent avoir des options pour définir des valeurs par défaut raisonnables pour les utilisateurs humains vs services, par exemple pour choisir un ID utilisateur dans la plage appropriée, et Demander un mot de passe pour un humain et désactiver l'authentification par mot de passe pour un service. Par exemple, adduser vs adduser --system Ou useradd vs useradd -r Sous Linux.

Answer 3

• 1. un compte de service, a.k.a., un compte technique est un compte conçu pour être utilisé uniquement par un service/une application, et non par un utilisateur régulier.
• 2. Les développeurs d'applications et de services souhaitent que ces comptes restreignent les droits et privilèges des processus associés au lieu d'exécuter leurs processus en tant que root. Les services démarrés par init, systemd ou similaire, qui s'exécutent en tant que root, rétrogradent rapidement vers le compte de service pour limiter les risques. Selon le système d'exploitation utilisé, les comptes d'application peuvent bénéficier de plus de privilèges que les comptes réguliers, par exemple le droit de se lier à un TCP TCP, ou au contraire voir leurs privilèges réduits par rapport à un utilisateur normal, par exemple en refusant aux processus de service d'appeler fork/exec. Dans ce cas, il n'est pas nécessaire que les services soient rétrogradés vers le compte de service, ils peuvent être démarrés avec celui-ci.
• 3. Vous ne devriez pas avoir besoin de créer un compte sans mot de passe utilisable et avec un shell non fonctionnel (par exemple /bin/false) et il ne sera pas utilisable par un utilisateur régulier, c'est-à-dire qu'il n'y aura aucun moyen de se connecter localement ou à distance (par exemple via ssh) en utilisant le nom du compte. Comme la plupart des limitations, l'utilisation du compte root ou Sudo permet de le surmonter.

Answer 4

Un compte de service peut ne pas avoir la possibilité d'utiliser un Shell par exemple. Il est utilisé pour exécuter des services (démon) avec une portée et des privilèges restreints. Mon avis est que vous pouvez le créer en tant qu'utilisateur régulier, tout en faisant attention aux droits et à l'appartenance au groupe. Cependant, la plupart du temps, ce n'est pas le cas, car les programmes les créent automatiquement lors de l'installation. Jetez un œil à/etc/passwdroot:x:0:0:root:/root:/bin/bash

0 est l'UID, il caractérise la hiérarchie du compte dans l'espace utilisateur, la racine est au-dessus de tout le monde, alors vous avez l'appartenance au groupe :root le répertoire personnel /root enfin le Shell utilisé par le compte /bin/bash pour "se connecter" au système.

Vous pouvez utiliser /usr/sbin/nologin pour un compte pour lequel vous ne souhaitez pas de privilège de connexion.