Comment empêcher même les utilisateurs de Root de désinstaller ou de modifier l'application sur MacOS

Le but est d'empêcher même les utilisateurs de Root de désinstaller notre application sur leur mac.

En tant que développeur tiers, vous ne pouvez pas empêcher l'utilisateur root ou les utilisateurs disposant de privilèges root de désinstaller des applications qu'ils peuvent, techniquement, installer eux-mêmes. Ce qu'un administrateur peut faire, un autre peut le (dé)faire.

Le système d'exploitation principal est protégé par SIP et si vous utilisez Catalina ou une version ultérieure, le volume système est en lecture seule. Ceci est mis en œuvre au niveau de la couche de base et non au niveau de la couche d'application où vous opérez.

Le service informatique peut toutefois gérer les autorisations, les droits et les rôles à l'aide d'un logiciel MDM (Mobile Device Management). Une fois qu'un appareil est inscrit, le service informatique pourra créer et appliquer des politiques autorisant/interdisant l'utilisation et l'installation de logiciels.

C'est à l'informatique de gérer cela, pas au développeur.

Vous allez devoir désactiver SIP en redémarrant en mode récupération, ouvrir une fenêtre de terminal et "csrutil disable" (puis redémarrer dans l'OS) et procéder au déchargement et à la suppression des fichiers kext restants. Depuis la version 10.15(catalina), les extensions du noyau ont été placées dans le dossier /System/Library et ne sont plus que des miroirs (ou des liens symboliques) dans le dossier /Library. Ainsi, afin de modifier les paramètres du système, vous devrez désactiver la protection du dossier /System (SIP) et ensuite procéder au déchargement des kexts que vous n'utiliserez pas.

Assurez-vous de réactiver csrutil (même méthode qu'avant ; utilisez la commande > csrutil enable).

De plus, il y a quelque temps (El capitain ou sierra [je ne me souviens plus maintenant et cela fait un moment que je n'ai pas désactivé les déchets inutiles qui sont livrés préchargés avec OSX]) ; quoi qu'il en soit ; -- il était possible de désactiver les kexts par le même terminal sur lequel vous pouviez désactiver SIP (mode de récupération) ou le mode utilisateur unique. Pour entrer en mode de démarrage utilisateur unique avec cmd+s pour entrer en mode de récupération avec cmd+r

Je vous conseille d'être prudent lorsque vous manipulez les paramètres du système ; certains peuvent rendre le système non opérationnel ou du moins... certains des services offerts pourraient être sévèrement entravés.

Une autre voie possible serait l'installation de "profils de configuration provisionnés" qui contournent/bloquent les processus internes (comme s'ils étaient installés par une organisation ou un MDM).

Je ne recommande pas d'essayer de verrouiller les administrateurs. Il est bien mieux de gérer l'accès des administrateurs, mais si vous insistez pour nager dans la direction opposée à celle d'Apple, commencez par un produit comme DeepFreeze.

• https://www.faronics.com/products/deep-freeze/

Leur solution de gestion Mac est la meilleure si vous voulez sacrifier les moyens modernes plus efficaces de contrôler les changements. Maintenant, une fois que vous avez évalué le prix de ce logiciel ou que vous avez souscrit à une solution "construite par nous-mêmes", cherchez à nouveau un partenariat avec Apple et apprenez à connaître la façon dont le DEP et le MDM fonctionnent pour atteindre tous vos objectifs et pas seulement le problème de la modification involontaire des fichiers.

Ce que vous recherchez, c'est la supervision MDM et l'inscription des appareils. C'est le moyen le plus efficace et le plus moderne de sécuriser les biens de l'entreprise et, en outre, vos inscriptions informatiques ne nécessiteront aucune intervention et seront appliquées par Apple. Mojave et les versions plus récentes sont assez bien conçus et Big Sur dispose de quelques leviers importants pour renforcer la sécurité contre la modification des fichiers, même sans DEP+MDM.

• http://business.apple.com
• https://www.apple.com/business/it/

Apple offre des conseils gratuits pour aider toute entreprise à s'engager dans cette voie et propose des services professionnels payants chaque fois que vous souhaitez une assistance de première partie ou des services améliorés au-delà des comptes gratuits de base nécessaires pour sécuriser correctement tous les appareils (Mac / iOS / iPadOS / tvOS / watchOS).

En imposant la notarisation et la signature du code, vous verrouillez toutes les modifications, qu'elles soient malveillantes ou générées par l'utilisateur.

Les extensions du noyau (KEXT) peuvent empêcher le système de les décharger. Comme ce n'est pas toujours une bonne idée de décharger une extension de noyau en cours d'utilisation, cela peut geler tout le système ou faire paniquer le noyau si vous le faites, il est demandé à une extension de noyau avant de la décharger si elle est d'accord avec cela et si elle le refuse, le système ne la déchargera pas. Bien sûr, un KEXT peut toujours prétendre que le déchargement serait un problème. Je ne peux donc pas le décharger à partir d'un système en fonctionnement.

Et un KEXT peut s'accrocher à l'API du système de fichiers pour surveiller tous les accès aux fichiers et empêcher certains types d'opérations sur les fichiers, par exemple une opération qui supprimerait le KEXT lui-même sur le disque ou tout outil d'aide à l'espace utilisateur (agent/daemon).

Donc, à première vue, ce système semble à l'épreuve des balles. Mais il ne l'est pas. Par exemple, rien ne m'empêche de démarrer en mode mono-utilisateur et de supprimer le KEXT dans ce mode. Rien ne m'empêche de démarrer le système de récupération et de supprimer le KEXT sur la partition principale. Rien ne m'empêche de démarrer à partir d'un disque externe et de supprimer les KEXT sur le disque interne. Et une fois supprimé, je peux démarrer le système interne normalement et rien ne m'empêchera de supprimer tout autre logiciel que je n'aime pas.

C'est une chose que les logiciels malveillants ne peuvent pas faire facilement et pas non plus sans que l'utilisateur devant l'ordinateur ne le remarque. Cela arrête donc les logiciels malveillants et a donc un sens pour un antivirus, mais cela n'empêche pas un être humain assis devant une telle machine de le faire.

Même le SIP ne peut protéger qu'un système en fonctionnement actif. Je peux démarrer en mode récupération et altérer tous les fichiers que je veux, même ceux qui sont habituellement protégés par SIP. Et la protection SIP n'est pas accessible aux développeurs tiers, c'est un système de protection destiné à protéger MacOS lui-même contre les manipulations par des logiciels malveillants et des pirates.

Et comme les KEXTs sont obsolètes avec MacOS 11 et le prochain MacOS 12, ce n'est pas une solution que j'envisagerais même pour commencer.