Das allgemeine Sicherheitsmodell sieht vor, dass normale Benutzer alle Startelemente zu ihrem Realm (Benutzerbibliothek für sie) und nicht für das System hinzufügen können, also lassen Sie die Leute keine Administratorkonten haben, wenn Sie ihnen nicht vertrauen, dass sie keine Software ausführen, die das Installationsprogramm ausführt Startelemente auf Systemebene.

Es gibt keine einfache Möglichkeit, einen Administrator daran zu hindern, das System zu ändern. Sie können Gatekeeper oder signierte Apps erzwingen, aber die meisten Admin-Benutzer können diese Einstellung umgehen, sodass Sie einen ungebildeten Admin-Benutzer bestenfalls ein wenig verlangsamen.

Jobs pro Benutzer und computerweit

Unter macOS kann launchd Hintergrundprozesse pro Benutzer und computerweit verwalten.

Innerhalb Ihrer Benutzersitzung existieren Pro-Benutzer-Jobs. Sie beginnen und enden, wenn Sie sich am Computer an- und abmelden. Wenn den Jobs Jobtickets zugeordnet sind, finden Sie diese im Ordner ~/Library/LaunchAgentsund~/Library/LaunchDaemons

Computerweite Jobs beginnen und enden mit dem Computer. Diese Jobs werden in /Library/LaunchAgentsund gespeichert /Library/LaunchDaemons.

Von Apple verwaltete computerweite Jobs werden in /System/Library/LaunchAgentsund gespeichert /System/Library/LaunchDaemons.

Pro-Benutzer-Jobs benötigen keine Superuser-Berechtigung. Sie mussten also keine sudoJobs stoppen, die auf Benutzerebene von installiert wurden vox.app.

Einen launchdJob deaktivieren

Sie können einen launchd-Job entladen, um die Rückgabe zu blockieren:

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

• -wDeaktiviert den Dienst zusätzlich, sodass zukünftige Ladevorgänge zu einem Dienst führen, der von launchd verfolgt wird, aber in keiner Weise gestartet oder entdeckt werden kann.
• -S <session>Entlädt nur die Dienste, die der angegebenen Sitzung zugeordnet sind.
• -D <domain>Entlädt launchd.plist(5)-Dateien aus der angegebenen Domäne. Weitere Einzelheiten finden Sie in der Diskussion zu demselben Flag, wenn es an den Lade-Unterbefehl übergeben wird.

Dies -wbewirkt, dass das Entladen auf die Festplatte geschrieben wird und über Sitzungen hinweg bestehen bleibt.

Weitere Informationen zum Stoppen, Entladen und Überschreiben von Jobs finden Sie unter:

• Launchctl Unterschied zwischen laden und starten, entladen und stoppen
• Dienste in OSX deaktivieren (services.msc)
• launchctl - aktivierte/deaktivierte Überschreibung entfernen

Das allgemeine Problem wird in Graham Milns Antwort behandelt. Diese Antwort ist nur eine geringfügige Ergänzung zu der angegebenen Beispielanwendung:

Kurzfassung: macOS hat einige spezielle Verzeichnisse für dieses Verhalten. Dies sind die globalen und Benutzer-/Library-Pfade, die bereits in Grahams Antwort erwähnt wurden. Ein weniger sichtbarer und damit weniger offensichtlicher Pfad befindet sich jedoch in jedem Anwendungspaket.

Einige Apps sind zu schlau. Vox ist ein Paradebeispiel dafür. Diese Agenten werden nicht gut erklärt, aber oft beklagt und sind daher ein potenziell unerwünschtes Programm, eine Anwendung oder Software (PUPAS).

Diese Anwendung löst bereits beim Kopieren nach /Applications und beim ersten Start eine Ereigniskette aus.

Im Paketbündel befinden sich LoginItems:

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

Beide werden vom systemeigenen DesktopServicesHelper als "Application Helper Login Item" kopiert/registriert. Solche „Helfer“ findet man oft auch in anderen Apps und sind meist nur störende Zusatzstoffe. Sie könnten durch praktische kleine Apps wie BlockBlock präventiv daran gehindert werden, sich überhaupt zu registrieren .

Da diese immer noch im App-Bundle enthalten sind, müssten Sie den Pfad innerhalb des App-Bundles suchen oder angeben!

Eine Suche nach automatisch gestarteten Programmen/Helfern muss /Applications und ~/Applications enthalten!

Ein weiteres Ärgernis findet sich dann innerhalb des App-Bundles :

 /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 

Eine Möglichkeit, diese benutzerspezifischen Prozesse daran zu hindern, Sie zu stören, wird in Grahams Antwort beschrieben, indem Sie launchctl.
Sie müssen nur auch in /Applications suchen.
Eine andere Methode wäre, in das Bündel zu gehen und diese Elemente einfach zu löschen . – Meistens starten diese Apps ohne sie gut, es fehlt nur die entsprechende Funktionalität. Vox war einst ein netter kleiner Musikplayer ohne Schnickschnack. Es funktioniert dafür ohne die auf der Festplatte vorhandenen Belästigungen.
Manchmal bieten Ihnen besser gestaltete Anwendungen eine Option, um diese Spielereien in ihrem Einstellungsdialog zu verhindern.

Persönlicher Favorit: Bei der Anwendung im angegebenen Beispiel wäre es am besten, die gesamte Anwendung zu löschen.

Um die Frage direkt zu beantworten Überschrift von

Warum kann eine App Daemons on the fly ohne sudo-Berechtigung erstellen und wie kann man dies stoppen?

Denn ein Benutzer startet die App mit seinen Rechten und Daemons, die in diesem Anwendungspaket enthalten sind, sind dann manchmal ziemlich ärgerlich so gestaltet, dass sie sich dann ziemlich intransparent als "Autostart" im Kontext dieses Benutzers und mit den Rechten dieses Benutzers registrieren. Zum Entladen oder Deregistrieren sind keine sudo/administrative Rechte oder Berechtigungen erforderlich. Wenn sich der Angreifer unter /Applications befindet, hängt die Entfernung möglicherweise von höheren Berechtigungen ab.