Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
sinter — Un système d'autorisation d'applications en mode utilisateur pour macOS écrit en Swift | Kitploit
Outils/GitHubGitHub/trailofbits/sinter
Outils DéfensifsAudit de ConfigurationRéponse aux IncidentsArchived
GitHubtrailofbits/sinter

sinter

Un système d'autorisation d'applications en mode utilisateur pour macOS écrit en Swift

Voir le dépôtSite web
29915il y a 5 ansVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

Sinter

Build Status

Sinter est un agent de sécurité des terminaux 100 % en mode utilisateur pour macOS 10.15 et versions ultérieures, écrit en Swift.

Sinter utilise l'API EndpointSecurity en mode utilisateur pour s'abonner et recevoir des rappels d'autorisation du noyau macOS, pour un ensemble de types d'événements liés à la sécurité. La version actuelle de Sinter prend en charge l'autorisation/le refus d'exécutions de processus ; dans les versions futures, nous prévoyons de prendre en charge d'autres types d'événements tels que les événements de fichier, de socket et de noyau.

Sinter est en cours de développement. Les retours sont les bienvenus. Si vous souhaitez contribuer ou nous sponsoriser pour nous aider à réaliser son potentiel, contactez-nous.

Fonctionnalités

  • Autoriser ou refuser l'exécution de processus par hachage de répertoire de code (alias « CD hash »)
    • option pour refuser tous les programmes inconnus (tout programme qui n'est pas explicitement autorisé)
    • option pour refuser tous les programmes non signés
    • option pour refuser tous les programmes avec des signatures invalides
  • mode « surveillance » pour suivre et journaliser (mais autoriser) tous les événements d'exécution de processus
  • Accepte les règles d'autorisation/refus d'un serveur de synchronisation Santa
  • Configurer les règles de refus en JSON, fournies localement ou par un serveur de synchronisation
  • Journaliser dans le système de fichiers local au format JSON structuré

Fonctionnalités prévues :

  • Refuser l'exécution de processus par chemin de fichier exécutable
  • Refuser l'exécution de processus par Team ID du certificat

Anti-Fonctionnalités

  • N'utilise pas d'extensions de noyau (qui seront officiellement dépréciées dans macOS 11 Big Sur)
  • Ne prend pas en charge macOS hérité (10.14 ou plus ancien)
  • N'utilise pas de code non sûr pour la mémoire
  • Limite les dépendances de bibliothèques tierces
  • N'est pas un anti-malware ou anti-virus. Pas de base de données de signatures. Refuse uniquement ce que vous lui dites de refuser, en utilisant des règles.

Contexte

La première solution open-source macOS pour autoriser/refuser les processus était Google Santa. Nous sommes fans de Santa, et avons contribué à sa base de code par le passé. Cependant, pendant longtemps, de nombreux membres de la communauté macOS ont demandé une solution open-source pour suivre et gérer plus que simplement les événements de processus.

Nous avons vu la plateforme idéale pour construire une telle capacité avec l'API EndpointSecurity dans macOS 10.15. Partir de zéro autour d'une API strictement en mode utilisateur signifiait que nous pouvions tenter une conception plus simple, et utiliser un langage de programmation moderne avec une gestion de mémoire plus sûre et de meilleures performances. Ainsi, nous avons entrepris de développer Sinter, abréviation de « Sinter Klausen », un autre nom pour le Père Noël.

Pour commencer

Téléchargez et installez la dernière version de Sinter en utilisant le lien d'installation pkg depuis la page Releases.

Après avoir installé Sinter, vous devez activer l'autorisation « Accès complet au disque » pour Sinter.app. Pour ce faire, ouvrez Préférences Système, onglet Sécurité et Confidentialité, puis Accès complet au disque. Cochez l'élément pour Sinter.app. Si vous utilisez MDM, vous pouvez activer automatiquement cette autorisation sur vos terminaux, et aucune interaction utilisateur ne sera nécessaire.

Configuration

Sinter nécessite qu'un fichier de configuration soit présent à l'emplacement /etc/sinter/config.json. Un exemple est fourni dans l'arborescence source à ./config/config.json :

root@kitploit:~
{
  "Sinter": {
    "decision_manager": "local",
    "logger": "filesystem",

    "allow_unsigned_programs": "true",
    "allow_invalid_programs": "true",
    "allow_unknown_programs": "true",
    "allow_expired_auth_requests": "true",
    "allow_misplaced_applications": "true",

    "config_update_interval": 600,

    "allowed_application_directories": [
      "/bin",
      "/usr/bin",
      "/usr/local/bin",
      "/Applications",
      "/System",
      "/usr/sbin",
      "/usr/libexec",
    ],
  },
  
  "FilesystemLogger": {
    "log_file_path": "/var/log/sinter.log",
  },

  "RemoteDecisionManager": {
    "server_url": "https://server_address:port",
    "machine_identifier": "identifier",
  },

  "LocalDecisionManager": {
    "rule_database_path": "/etc/sinter/rules.json",
  }
}

Le plugin de gestionnaire de décision peut être sélectionné en modifiant la valeur decision_manager. Le plugin local activera la section de configuration LocalDecisionManager, pointant Sinter vers la base de règles locale présente au chemin donné. Il est possible d'utiliser un serveur de synchronisation compatible Santa, en utilisant plutôt le plugin sync-server. Cela active la section de configuration RemoteDecisionManager, où l'URL du serveur et l'identifiant de la machine peuvent être définis.

Deux plugins de journalisation sont actuellement implémentés :

  1. filesystem : Les messages sont écrits dans un fichier, en utilisant le chemin spécifié dans FilesystemLogger.log_file_path
  2. unifiedlogging : Les journaux sont émis via Unified Logging, en utilisant com.trailofbits.sinter comme sous-système.

Répertoires d'applications autorisés

Il est possible de configurer Sinter pour journaliser et éventuellement refuser les applications qui n'ont pas été démarrées depuis un dossier autorisé.

  • allow_misplaced_applications : Si défini sur true, les applications mal placées généreront seulement un avertissement. Si défini sur false, toute exécution qui ne démarre pas depuis un chemin valide est refusée.
  • allowed_application_directories : Si non vide, il sera utilisé pour déterminer si les applications sont placées dans le mauvais dossier.

Activation des notifications UI

  1. Installer le serveur de notifications (l'installateur PKG le fera automatiquement) : sudo /Applications/Sinter.app/Contents/MacOS/Sinter --install-notification-server
  2. Démarrer l'agent : /Applications/Sinter.app/Contents/MacOS/Sinter --start-notification-server

Configuration de Sinter en mode MONITOR

Les modes ne sont pas implémentés dans Sinter, car tout est basé sur des règles. Il est possible d'implémenter la fonctionnalité de surveillance en ajustant les paramètres suivants :

  • allow_unsigned_programs : autoriser les applications qui ne sont pas signées
  • allow_invalid_programs : autoriser les applications qui échouent à la vérification de signature
  • allow_unknown_programs : autoriser automatiquement les applications qui ne sont pas couvertes par la base de règles active
  • allow_expired_auth_requests : l'API EndpointSecurity exige que Sinter réponde aux demandes d'autorisation dans un délai non spécifié (généralement moins d'une minute). Les applications volumineuses, comme Xcode, prendront un temps considérable à vérifier. Ces exécutions sont refusées par défaut, et l'utilisateur doit réessayer une fois l'application vérifiée. Définir cette configuration sur true change ce comportement afin que ces demandes soient toujours autorisées.

Format des règles

Les bases de règles sont écrites au format JSON. Voici un exemple de base de données qui autorise le bundle d'application CMake de cmake.org :

root@kitploit:~
{
  "rules": [
    {
      "rule_type": "BINARY",
      "policy": "ALLOWLIST",
      "sha256": "BDD0AF132D89EA4810566B3E1E0D1E48BAC6CF18D0C787054BB62A4938683039",
      "custom_msg": "CMake"
    }
  ]
}

Sinter ne prend en charge que les règles BINARY pour l'instant, en utilisant les politiques ALLOWLIST ou DENYLIST. La valeur du hachage du répertoire de code peut être extraite de la sortie de l'outil codesign (exemple : codesign -dvvv /Applications/CMake.app). Notez que même si les outils CLI peuvent obtenir le hachage SHA256 complet, l'API Kernel/EndpointSecurity est limitée aux 20 premiers octets.

Compilation à partir des sources

La compilation de Sinter nécessite certains certificats de signature de code et droits qu'Apple doit accorder à votre organisation. Cependant, Sinter peut toujours être compilé à partir des sources et exécuté localement sur un système de test avec SIP désactivé. Pour les instructions, consultez le wiki de Sinter.

Licence

Sinter est sous licence et distribué sous la licence AGPLv3. Contactez-nous si vous cherchez une exception aux conditions.

Télécharger l’outil