northpolesec/santaUn système d'autorisation d'accès aux binaires et aux fichiers pour macOS.
# Santa
[](https://github.com/northpolesec/santa/blob/main/LICENSE)
[](https://github.com/northpolesec/santa/actions/workflows/ci.yml)
[](https://github.com/northpolesec/santa/releases/latest)
[](https://github.com/northpolesec/santa/releases/latest)
[](https://github.com/northpolesec/santa/releases/latest)
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/48928/e1bf85722063ce270cf9ebed27d2da2b32338868376dfcec597f25f0bd1b8d4a.png" height="128" alt="Santa Icon" />
</p>
Santa est un système d’autorisation d’accès aux binaires et aux fichiers pour macOS. Il se compose
d’une extension système qui surveille les exécutions et les accès aux fichiers, et prend
des décisions en fonction du contenu d’une base de données locale, d’un agent graphique qui notifie
l’utilisateur en cas de décision de blocage, d’un service d’arrière-plan chargé de synchroniser
la configuration avec un serveur distant, et d’un utilitaire en ligne de commande pour gérer
le système.
Il est nommé Santa parce qu’il garde la trace des binaires qui sont sages ou pas sages.
# Docs
La documentation de Santa est stockée dans le répertoire
[Docs](https://github.com/northpolesec/santa/blob/main/docs) et est publiée
à l’adresse https://northpole.dev.
La documentation comprend les options de déploiement, des détails sur le fonctionnement de certaines parties de Santa ainsi que
des instructions pour développer Santa lui-même.
# Obtenir de l’aide
Si vous avez des questions ou si vous avez besoin d’aide pour démarrer,
le canal [#santa sur le slack macadmins](https://app.slack.com/client/T04QVKUQG/C0E1VRBGW) est un excellent point de départ.
Si vous pensez avoir trouvé un bug, n’hésitez pas à signaler [un
problème](https://github.com/northpolesec/santa/issues) et nous répondrons dès que
possible.
Si vous pensez avoir trouvé une vulnérabilité, veuillez lire la
[politique de sécurité](https://github.com/northpolesec/santa/security/policy) pour
la divulgation.
# Fonctionnalités
* Plusieurs modes : dans le mode MONITOR par défaut, tous les binaires, sauf ceux marqués
comme bloqués, sont autorisés à s’exécuter, tout en étant journalisés et enregistrés dans
la base de données des événements. Dans le mode LOCKDOWN, seuls les binaires listés sont autorisés à
s’exécuter.
* Journalisation des événements : lorsque l’extension système est chargée, tous les lancements de binaires sont
journalisés. Dans les deux modes, tous les binaires inconnus ou refusés sont stockés dans la
base de données pour permettre une agrégation ultérieure.
* Règles basées sur la signature de code, avec niveaux de priorité : au lieu de se fier au
hash (ou « empreinte ») d’un binaire, les exécutables peuvent être autorisés/bloqués par
leur signature de code (via des règles CDHash, Certificate, TeamID ou SigningID). Vous
pouvez donc autoriser/bloquer tous les binaires signés par un éditeur ou toutes les versions
d’un binaire signé. Les règles sont appliquées par ordre de spécificité, ce qui vous permet
d’autoriser tous les binaires d’un éditeur donné tout en bloquant un ID de signature
ou un binaire spécifique (ou l’inverse).
* Règles basées sur les chemins (via NSRegularExpression/ICU) : cela offre une fonctionnalité similaire
à celle de Managed Client (le précurseur des profils de configuration,
qui utilisait le même mécanisme d’implémentation), Application Launch
Restrictions via le binaire mcxalr. Cette implémentation présente l’avantage
supplémentaire d’être configurable via des expressions régulières, sans dépendre de LaunchServices.
Comme détaillé dans le wiki, lors de l’évaluation des règles, elle a la priorité la plus basse.
* Règles de certificat infaillibles : vous ne pouvez pas créer de règle de refus qui bloquerait le
certificat utilisé pour signer launchd, c’est-à-dire pid 1, et donc tous les composants
utilisés dans macOS. Les binaires de chaque mise à jour du système (et dans certains cas de versions
entièrement nouvelles) sont donc automatiquement autorisés. Cela n’affecte pas les binaires
de l’App Store d’Apple, qui utilisent divers certificats changeant régulièrement pour les
applications courantes. De même, vous ne pouvez pas bloquer Santa lui-même.
* Les composants de l’espace utilisateur se valident mutuellement : chacun des composants de l’espace utilisateur (le
démon, l’agent graphique et l’utilitaire en ligne de commande) communique entre
eux via XPC et vérifie que leurs certificats de signature sont identiques
avant qu’une communication ne soit acceptée.
* Mise en cache : les binaires autorisés sont mis en cache afin que le traitement nécessaire à une
requête ne soit effectué que si le binaire n’est pas déjà en cache.
# Intentions et attentes
Aucun système ni processus unique ne stoppera *toutes* les attaques, ni ne fournira une sécurité à 100 %.
Santa est écrit dans l’intention d’aider à protéger les utilisateurs contre eux-mêmes.
Les gens téléchargent souvent des logiciels malveillants et leur font confiance, donnant aux logiciels malveillants des identifiants, ou
permettant à des logiciels inconnus d’exfiltrer davantage de données sur votre système. En tant que
composant géré de manière centralisée, Santa peut aider à stopper la propagation de logiciels malveillants au sein d’un
grand parc de machines. Indépendamment, Santa peut aider à analyser ce qui
s’exécute sur votre ordinateur.
Santa fait partie d’une stratégie de défense en profondeur, et vous devriez continuer à
protéger les hôtes par tous les autres moyens que vous jugez appropriés.
# Problèmes connus
* Santa bloque uniquement l’exécution (execve et variantes), il ne protège pas contre
les bibliothèques dynamiques chargées avec dlopen, les bibliothèques sur disque qui ont été
remplacées, ou les bibliothèques chargées via `DYLD_INSERT_LIBRARIES`. D’autres parties de
macOS protègent généralement contre ces voies, tant que SIP est activé.
* Scripts : Santa est actuellement conçu pour ignorer toute exécution qui n’est pas un
binaire. Cela s’explique par le fait qu’après avoir pesé le coût administratif par rapport aux
bénéfices, nous avons constaté que cela n’en valait pas la peine. De plus, un certain nombre
d’applications utilisent des scripts temporaires générés, que nous ne pouvons pas
inscrire sur une liste blanche et ne pas le faire causerait des problèmes. Nous sommes ravis de reconsidérer cela
(ou du moins d’en faire une option) si cela peut être utile à d’autres.
# Serveurs de synchronisation
* Santa peut synchroniser ses paramètres et ses politiques avec un serveur de gestion,
ce qui permet des changements de configuration très rapides.
Plusieurs serveurs commerciaux et open-source sont disponibles :
* [Workshop](https://northpole.security) - Workshop est le serveur de synchronisation
officiel proposé par North Pole Security. Il est complet, rapide,
évolutif et prêt pour l’entreprise.
* [Moroz](https://github.com/groob/moroz) - Un simple serveur golang qui
sert des règles codées en dur à partir de fichiers de configuration simples.
* [Rudolph](https://github.com/airbnb/rudolph) - Un service de synchronisation serverless basé sur AWS,
principalement construit sur des composants API GW, DynamoDB et Lambda afin de réduire la charge opérationnelle.
Rudolph est conçu pour être rapide, facile à utiliser et rentable.
* [Zentral](https://github.com/zentralopensource/zentral/wiki) - Un
service centralisé qui collecte des données provenant de multiples sources et déploie des
configurations vers de multiples services.
* Alternativement, les règles peuvent être configurées localement en utilisant soit la
clé de configuration [StaticRules](https://northpole.dev/configuration/keys#StaticRules),
soit la commande `santactl rule`.
# Captures d’écran
Un outil comme Santa ne se prête pas vraiment aux captures d’écran, alors voici une vidéo
à la place.
<p align="center"> <img src="https://assets.kitploit.com/production/public/readmes/48928/a825753c75f19eaa65d7d4ab6d9d70b8280b9877d766f6f8cda431d7b8d5d8fd.gif" alt="Santa Block Video" /> </p>
# Contribuer
Les corrections apportées à ce projet sont les bienvenues. Veuillez consulter le
document [CONTRIBUTING](https://northpole.dev/development/contributing).
# Avertissement
North Pole Security et North Pole Security Santa ne sont pas affiliés à
Google.