Clamav est un démon. La spécification Linux Standard Base Core recommande que les démons s'exécutent sous des ID utilisateur individuels. De cette façon, vous avez un contrôle d'accès précis pour chaque démon, et au cas où l'un d'entre eux serait compromis, l'attaquant n'a pas automatiquement un accès illimité au système (comme il le ferait si le démon s'exécutait en tant que root, par exemple).

Tous les conseils de bon sens qui s'appliquent à la compréhension de ce genre de situation

Toute application a besoin d'un compte pour s'exécuter. Exécuter toutes les applications avec un compte root peut être dangereux. Dans le cas où une telle application a un bogue critique, par exemple il permet l'exécution d'autres applications dans le système, le succès des attaques possibles dépend essentiellement des autorisations de cette application.

Si cette application est exécutée avec un compte root, toutes les actions qu'elle exécute seront acceptées et effectuée par le système. Cela signifie qu'une attaque peut réussir. Mais si l'application s'exécute avec un compte restreint avec moins d'autorisations, alors de nombreuses actions malveillantes seront impossibles car le système refusera de les exécuter.

L'utilisation d'un compte séparé permet de contrôler les autorisations nécessaires au application particulière plus précisément. Vous pouvez donner à ce compte exactement les autorisations dont il a besoin et pas plus. En outre, vous pouvez retirer rapidement les autorisations de ces comptes ou même les supprimer. Avoir un compte séparé permet à l'application de protéger ses données (fichiers de configuration, fichiers journaux) des autres utilisateurs sans avoir besoin du compte root.

C'est l'idée.

Dans la réalité nous devons garder à l'esprit ce qui suit:

1) Il se peut que la granularité des autorisations soit trop grossière et que vous deviez donner plus d'autorisations que vous ne le souhaiteriez.

2 ) Le maintien d'un compte distinct pour chaque application (processus, service, démon) nécessite des efforts. C'est pourquoi nous estimons les risques et prenons en compte les efforts. Si les risques sont faibles, il est logique de limiter les efforts et de maintenir le moins de comptes possible.

3) De nombreuses applications ont un compte utilisateur configurable avec lequel elles fonctionneront. Son nom est similaire au nom de l'application. C'est à vous de le conserver ou d'utiliser un autre compte utilisateur pour cette application.

4) En ce qui concerne clamav: avoir un compte séparé n'est pas suspect, c'est normal.

Les applications exécutent souvent un script en tant que root lors de l'installation. Ce script peut utiliser les droits root pour créer le compte d'utilisateur limité qui n'a que les autorisations requises par le programme. C'est une approche normale et bonne.

En cas de doute, utilisez

  ps -e -f  

pour voir la ligne de commande dans l'exhaustivité et vérifier où se trouve le binaire en cours d'exécution localisé.

Les programmes avec un support d'installation moins étendu nécessitent que l'administrateur crée ces comptes et scripts pour y accéder.

Est-il habituel qu'un programme revendique son propre profil utilisateur pour s'exécuter lui-même?

Il est normal que les programmes qui s'exécutent en arrière-plan s'exécutent en tant que leurs propres utilisateurs.

Est-ce en fait un bon signe, car cela ajoute de la transparence à ce qui se passe de toute façon?

C'est bien parce qu'il fournit une séparation des privilèges, si tous les programmes d'arrière-plan exécuté comme le même utilisateur, alors un compromis sur l'un pourrait plus facilement se propager aux autres, cela aide également à la surveillance.

Est-ce en fait un mauvais signe, car un tel utilisateur ad-hoc peut s'immiscer sur d'autres choses?

Il est certainement sous-optimal que les systèmes de type Unix ne maintiennent pas de distinction dans les noms d'utilisateur entre les utilisateurs humains et les utilisateurs système, mais c'est une vieille conception qui est très difficile à utiliser back and fix: (. Debian recommande maintenant un préfixe de soulignement pour les noms d'utilisateur système nouvellement ajoutés, mais il ne semble pas y avoir de désir d'essayer de changer la multitude des noms existants.

Puis-je récupérer une liste des programmes installés sur mon ordinateur revendiquant ce droit de travailler avec un propre nom d'utilisateur? Fondamentalement, un utilisateur peut-il superviser de tels comportements?

En règle générale sur les systèmes de type Debian, les utilisateurs système peuvent être distingués en ayant des identifiants entre 0 et 999 alors que les utilisateurs normaux le feront ont normalement des ID utilisateur compris entre 1000 et 59999 (voir https://www.debian.org/doc/debian-policy/ch-opersys.html pour plus de détails)

En ce qui concerne les programmes qui utilisent réellement chaque utilisateur, ce qui peut être plus difficile à dire, vous pouvez parfois le trouver dans un script d'initialisation, un fichier de service systemd, une tâche cron, etc., mais certains services démarrent en root, puis descendent vers leur utilisateur spécifique après certains les tâches d'initialisation privilégiées (principalement liées aux ports TCP / UDP privilégiés) sont terminées.

Est-il habituel qu'un programme revendique son propre profil utilisateur pour s'exécuter lui-même?

Comme mentionné dans d'autres réponses, ce n'est pas un programme régulier. C'est un démon. Et, oui, il est parfaitement normal qu'un démon ait son propre utilisateur.

Est-ce vraiment un bon signe, car cela ajoute de la transparence à ce qui se passe de toute façon?
Est-ce vraiment un mauvais signe, parce qu'un tel utilisateur ad hoc peut empiéter sur d'autres choses?

Ce n'est ni bon ni mauvais. C'est simplement une question de commodité. Sur un système Linux, tous les processus doivent avoir certains utilisateurs. Il n'est pas possible d'avoir un processus sans utilisateur. Alors, quel utilisateur? Pas root, car vous ne devriez jamais rien exécuter en tant que root sauf si vous devez absolument le faire. Vous pouvez simplement choisir un utilisateur, mais que se passe-t-il si cet utilisateur est supprimé? Il est beaucoup plus simple pour l'installateur / le gestionnaire de paquets / quoi que ce soit de créer simplement un utilisateur et de l'utiliser.

Cela dit, pour certains démons (en particulier ceux liés au réseau), il y a des avantages en matière de sécurité. Si quelqu'un est capable de compromettre à distance un démon réseau, il n'aura (en théorie) accès qu'aux fichiers auxquels le démon a pu accéder à l'origine, c'est-à-dire les fichiers appartenant à cet utilisateur.

Puis-je récupérer une liste des programmes installés sur mon ordinateur revendiquant ce droit de travailler avec un propre nom d'utilisateur? Fondamentalement, un utilisateur peut-il superviser de tels comportements?

Changer d'utilisateur est un "droit" de chaque processus qui s'exécute en tant que root. Étant donné que les démons sont (généralement) lancés par la procédure de démarrage du système, ils démarrent (généralement) en tant que root, ils sont donc (généralement) libres de modifier arbitrairement leurs propres identifiants utilisateur. Même après avoir abandonné le privilège root (s'ils le font, rien ne les empêche de continuer en tant que root), ils peuvent conserver la possibilité de changer leur identifiant d'utilisateur s'ils en ont besoin. Donc, non, il n'y a pas de référentiel central d'informations sur les démons qui changeront leur identifiant d'utilisateur au démarrage, et lesquels ne le feront pas.

Cependant, il existe une convention selon laquelle les ID utilisateur inférieurs à 1 000 sont réservés aux utilisateurs du démon. Vous pouvez donc consulter / etc / passwd pour trouver des identifiants d'utilisateurs à faible nombre.