Le modèle de sécurité général est que les utilisateurs normaux peuvent ajouter n'importe quel élément de démarrage à leur domaine (bibliothèque de l'utilisateur pour eux) et non pour le système, donc ne laissez pas les gens avoir des comptes d'administrateur si vous ne leur faites pas confiance pour ne pas exécuter des logiciels qui installent des éléments de démarrage au niveau du système.

Il n'existe pas de moyen simple d'empêcher un utilisateur administrateur de modifier le système. Il est possible d'imposer des applications signées ou de type "gatekeeper", mais la plupart des utilisateurs administratifs peuvent contourner ce paramètre, de sorte qu'au mieux, vous ralentissez un peu un utilisateur administratif non éduqué.

Emplois par utilisateur et par ordinateur

Sur MacOS, lancementd peut gérer les processus d'arrière-plan par utilisateur et à l'échelle de l'ordinateur.

Les travaux par utilisateur existent au sein de votre session utilisateur. Ils démarrent et s'arrêtent lorsque vous vous connectez et vous déconnectez de l'ordinateur. Si les tâches sont associées à des fiches de travail, vous les trouverez dans le dossier ~/Library/LaunchAgents y ~/Library/LaunchDaemons

Les emplois à l'échelle de l'ordinateur commencent et s'arrêtent avec l'ordinateur. Ces travaux sont stockés dans /Library/LaunchAgents y /Library/LaunchDaemons .

Les travaux sur l'ensemble de l'ordinateur gérés par Apple sont stockés dans /System/Library/LaunchAgents y /System/Library/LaunchDaemons .

Les travaux par utilisateur n'ont pas besoin de l'autorisation du super-utilisateur. Vous n'avez donc pas besoin de sudo pour arrêter les travaux installés au niveau de l'utilisateur par vox.app .

Désactivation d'un launchd emploi

Vous pouvez décharger une tâche launchd pour empêcher son retour :

Utilisation : launchctl unload <service-path, service-path2, ...>

• -w En outre, il désactive le service de sorte que les futures opérations de chargement se traduiront par un service que launchd suivra, mais qui ne pourra pas être lancé ou découvert de quelque manière que ce soit.
• -S <session> Décharge uniquement les services associés à la session spécifiée.
• -D <domain> Décharge les fichiers launchd.plist(5) du domaine spécifié. Voir la discussion concernant ce même drapeau lorsqu'il est donné à la sous-commande load pour plus de détails.

En -w entraîne l'écriture de la décharge sur le disque et sa persistance d'une session à l'autre.

Pour en savoir plus sur l'arrêt, le déchargement et l'annulation des travaux, voir :

• Launchctl différence entre load et start, unload et stop
• Désactiver les services dans OSX (services.msc)
• launchctl - supprimer l'annulation de l'activation/désactivation

Le problème général est traité dans la réponse de Graham Miln. Cette réponse n'est qu'un léger complément apporté à l'exemple d'application donné :

Version courte : MacOS dispose de quelques répertoires spéciaux pour ce type de comportement. Il s'agit des chemins global et utilisateur /Library déjà mentionnés dans la réponse de Graham. Mais un chemin moins visible et donc moins évident se trouve à l'intérieur de chaque paquet d'applications.

Certaines applications sont trop intelligentes. Vox en est un excellent exemple. Ces agents ne sont pas bien expliqués mais font souvent l'objet de plaintes et sont donc des programmes, applications ou logiciels potentiellement indésirables (PUPAS).

Cette application déclenche une chaîne d'événements dès qu'elle est copiée dans /Applications et à nouveau lorsqu'elle est lancée pour la première fois.

Le paquet contient des LoginItems :

   /Volumes/VOX/VOX.app/Contents/Library/LoginItems
  ../Loop.app
  ../VOX Agent.app

Ces deux éléments sont copiés/enregistrés par le DesktopServicesHelper du système en tant qu'"élément de connexion d'aide à l'application". Ce type d'"aide" se trouve souvent dans d'autres applications et n'est généralement qu'une nuisance supplémentaire. Ils peuvent être empêchés de façon préventive de s'enregistrer en premier lieu par de petites applications pratiques, telles que BlockBlock .

Comme ils sont encore contenus dans le paquet d'applications vous devez rechercher ou fournir le chemin d'accès à l'intérieur de l'ensemble d'applications !

Une recherche de programmes/aides lancés automatiquement doit inclure /Applications et ~/Applications !

Une autre gêne est alors constatée dans le paquet d'applications :

 /Volumes/VOX/VOX.app/Contents/XPCServices 
 /Volumes/VOX/VOX.app/Contents/XPCServices/VOX\ Toolbox.xpc
 /Volumes/VOX/VOX.app/Contents/XPCServices/com.coppertino.Vox.GNTPClientService.xpc 

Une façon de désactiver ces processus par utilisateur est décrite dans la réponse de Graham. launchctl .
Il vous suffit de faire une recherche dans /Applications.
Une autre méthode consisterait à aller dans la liasse et à simplement supprimer ces éléments. - La plupart du temps, ces applications démarrent très bien sans ces éléments, mais il leur manque simplement les fonctionnalités correspondantes. Vox était autrefois un agréable petit lecteur de musique "sans fioritures". Il fonctionne pour cela sans les inconvénients présents sur le disque.
Parfois, des applications mieux conçues vous offrent une option pour empêcher ces manigances dans leur dialogue de préférences.

Mon coup de cœur : Dans le cas de l'application de l'exemple donné, il serait préférable de supprimer l'ensemble de l'application.

Pour répondre directement à la question du titre de

Pourquoi une application peut-elle créer des démons à la volée sans la permission de sudo et comment l'arrêter ?

Parce qu'un utilisateur lance l'application avec ses privilèges et que les démons contenus dans ce paquet d'applications sont alors parfois conçus de manière assez ennuyeuse pour s'enregistrer de manière assez intransparente en tant que "démarrage automatique" dans le contexte de cet utilisateur et avec les droits de cet utilisateur. Pour décharger ou désenregistrer, aucun droit ou autorisation sudo/administratif n'est nécessaire. Si l'auteur de l'infraction se trouve sous /Applications, la suppression peut dépendre d'autorisations plus élevées.