Pourquoi on ne peut pas se fier aux réglages Privacy & Security de macOS

• Il a été constaté que les réglages Privacy & Security de macOS ne reflètent pas l’état réel des autorisations d’accès
• Même lorsque l’accès au dossier Documents est bloqué, l’app Insent peut encore lire les fichiers
• Lorsque l’utilisateur sélectionne directement le dossier, le système TCC considère cela comme un accès intentionnel et lève les restrictions
• L’écran des réglages affiche l’accès comme bloqué, mais en réalité les contraintes du sandbox sont levées et l’accès reste autorisé
• Pour bloquer complètement l’accès, une commande Terminal et un redémarrage sont nécessaires, ce qui peut entraîner un risque de perte de contrôle pour l’utilisateur

---

Problème de fiabilité des réglages Privacy & Security de macOS

• Un cas a confirmé que les réglages Privacy & Security de macOS ne reflètent pas correctement l’état réel des autorisations d’accès
  • Avec une app simple appelée Insent, on constate qu’il est possible d’accéder au dossier Documents même lorsque cet accès est indiqué comme bloqué dans les réglages
  • Ce problème peut être reproduit de la même façon à partir de macOS 13.5

• Fonctionnement de l’app Insent

  • Le bouton Open by consent ouvre et affiche un fichier texte quelconque du dossier Documents après consentement de l’utilisateur
  • Le bouton Open from folder ouvre et affiche un fichier du dossier lorsque l’utilisateur sélectionne lui-même ce dossier
  • Dans ce second cas, l’intention de l’utilisateur est considérée comme une autorisation d’accès, et le système TCC (Transparency, Consent, and Control) autorise l’accès sans demande de consentement supplémentaire

• Procédure de test et résultats

  • Après avoir autorisé l’accès à Documents, on vérifie qu’Insent lit normalement le fichier
  • Ensuite, lorsque l’accès d’Insent à Documents est désactivé dans les réglages Privacy & Security, l’accès est bloqué
  • Cependant, si l’on sélectionne Documents avec Open from folder, l’accès redevient possible, et ensuite Open by consent fonctionne lui aussi sans restriction
  • L’écran des réglages continue d’indiquer que l’accès est bloqué, mais en réalité Insent peut toujours accéder au dossier Documents
  • Pour bloquer complètement l’accès, il faut exécuter la commande tccutil reset All co.eclecticlight.Insent puis redémarrer le Mac

• Analyse du fonctionnement interne

  • Insent est une app notariée standard, sans sandbox ni privilèges spéciaux
  • Lorsque System Integrity Protection (SIP) est activé, certaines opérations sont traitées dans le sandbox
  • sandboxd intercepte les requêtes d’accès aux fichiers et envoie à TCC une demande d’autorisation ; si l’utilisateur consent, l’accès est accordé
  • Une fois l’accès désactivé, TCC le refuse, mais si l’utilisateur sélectionne le dossier via le panneau Open/Save, sandboxd n’intercepte plus la requête
  • En conséquence, TCC ne contrôle plus l’accès, et le dossier reste accessible avec les contraintes du sandbox levées

• Cause du problème

  • Lorsqu’un accès basé sur l’intention de l’utilisateur se produit, les contraintes du sandbox sur ce dossier sont supprimées
  • Ce changement n’est pas reflété dans l’interface des réglages Privacy & Security ; l’accès semble donc bloqué dans les réglages alors qu’il reste en réalité autorisé
  • D’autres dossiers protégés (par ex. Desktop, Downloads) fonctionnent normalement, et le problème se produit de façon indépendante selon les dossiers

• Conclusion

  • L’indication de restriction d’accès dans la rubrique Files & Folders n’est pas fiable quant à l’état réellement appliqué

    • Même si une app n’apparaît pas dans la liste ou semble bloquée, elle peut en réalité accéder à un dossier protégé dans certains cas
    • Une fois l’autorisation accordée, elle ne peut pas être retirée sans commande Terminal et redémarrage, ce qui risque de faire perdre à l’utilisateur le contrôle de l’accès

• Discussion complémentaire (résumé des commentaires)

  • Après l’expérience, un attribut étendu com.apple.macl a été ajouté au dossier Documents, et on suppose qu’il permet l’accès à Insent
  • La commande tccutil reset supprime les entrées macl de la base de données, mais les xattr (attributs étendus) restent en place, ce qui peut maintenir l’accès
  • Lorsque SIP est activé, il est difficile de supprimer cet attribut, et il ne peut être effacé qu’en mode de récupération avec la commande xattr -d com.apple.macl path/to/Documents
  • Il devient ainsi difficile pour l’utilisateur de vérifier ou de contrôler l’état réel d’accès d’une app

[GN⁺]

Avis sur Hacker News

• À mes yeux, cela semblait être un problème assez simple. Si on donne à une app l’autorisation d’accéder à un dossier, il est naturel de s’attendre à ce qu’elle puisse aussi accéder aux fichiers qu’il contient

  • Il faut lire la documentation attentivement. Le réglage Files & Folders ne reflète pas fidèlement l’état réel des autorisations. Même si l’interface montre que l’accès est bloqué, l’app peut toujours avoir un accès illimité au dossier Documents
  • Le point essentiel, c’est que « l’autorisation a été accordée puis désactivée dans l’interface, mais l’accès reste malgré tout possible »
  • Le début de l’article précise d’ailleurs que « les réglages de sécurité peuvent afficher de manière erronée l’état réel d’accès d’une app »
  • On pouvait s’attendre à ce que macOS reconnaisse les dossiers déjà liés dans l’interface et les relie correctement en arrière-plan, mais cela est traité comme une simple exception de chemin, ce qui désactive l’interface. J’imagine que cela a dû être signalé via un rapport de feedback. L’auteur traite souvent de problèmes liés à Gatekeeper ou à TCC, donc je comprends bien sa réaction
  • L’article est rédigé de façon trop ambiguë. Il explique insuffisamment quel est le mécanisme qui permet à l’accès de subsister après la révocation de l’autorisation

• Après avoir lu l’article, j’ai révoqué toutes les autorisations sur les dossiers et fait un test : Insent pouvait toujours lire Documents alors que l’interface affichait « None ». Cela ressemble à un échec de transparence

  • On peut aussi se demander si une app n’a pas, par défaut, accès au dossier personnel de l’utilisateur

• Voilà toute l’ironie d’un OS centré sur le GUI. Pour bloquer complètement l’accès au dossier Documents, il faut exécuter dans le terminal
  tccutil reset All co.eclecticlight.Insent
  puis redémarrer

  • Jobs se retournerait dans sa tombe. Apparemment, il y avait déjà beaucoup de conflits de ce type entre GUI et CLI à l’époque de NeXT
  • Il y a aussi des comportements étranges côté GUI. J’avais éteint le Wi‑Fi avant d’arrêter la machine, mais au démarrage, pendant la connexion, l’icône Wi‑Fi a semblé s’activer brièvement avant de redevenir désactivée. Impossible de dire si ce n’est qu’un bug d’interface ou si le Wi‑Fi s’allume réellement un instant

• Le titre serait plus exact s’il était reformulé en « les apps macOS conservent l’accès à un dossier même quand l’utilisateur le révoque »

  • Mais en réalité, l’utilisateur n’a pas révoqué un accès spécifique ; il a seulement désactivé l’accès général au dossier. Il n’existe aucun moyen de retirer individuellement des accès plus fins

• Le système de sandbox du Mac rappelle le Windows UAC. C’est une structure qui ne fait qu’accroître la fatigue de l’utilisateur.
  Je trouve que l’approche de conteneurisation optionnelle des systèmes *nix est bien meilleure.
  Le fait qu’un processus en arrière-plan lancé depuis Terminal conserve ses autorisations même après la mort du processus parent est particulièrement étrange. Cela donne l’impression que tout le modèle d’autorisations est surtout formel

  • Apple devrait revoir ses anciennes publicités (lien YouTube)
  • À noter que l’UAC n’est pas une frontière de sécurité, donc un UAC-bypass n’est pas considéré comme une vulnérabilité d’élévation de privilèges
  • Le problème plus profond, c’est qu’un grand nombre de développeurs restent bloqués dans un vieux paradigme où « tout peut accéder à tout ». L’UX de macOS n’est pas parfaite, mais un accès illimité par défaut est encore plus dangereux
  • En plus, Apple prévoit des exceptions pour ses propres apps afin de ne pas dégrader l’expérience utilisateur
  • Il ne s’agit pas de la sandbox du Mac, mais du système TCC. Les apps utilisant l’App Sandbox ne peuvent même pas afficher l’invite d’accès à Documents. À la place, elles peuvent conserver l’accès via des Security Scoped Bookmark (lien de référence)

• En plus de tccutil reset, on peut aussi réinitialiser en activant puis désactivant l’autorisation dans les réglages de sécurité.
  L’interface affiche simplement un mauvais état à cause d’un bug, mais les autorisations réelles fonctionnent normalement.
  La couleur des cases à cocher varie aussi selon l’état du focus, ce qui prête à confusion. C’est toujours le cas dans la version Sequoia.
  Il est aussi intéressant de voir les jeux installés sur des disques externes demander l’accès aux « removable volumes » et remplir toute la liste

• On ne sait pas trop s’il s’agit d’un bug, d’une faille de sécurité ou d’une simple erreur. Je me demande s’il vaut mieux exécuter la commande de reset pour toutes les apps

  • Ce n’est qu’une omission dans l’interface. Le système interne fonctionne correctement
  • Ce genre de problème relève d’un bug d’interface de sécurité. Comme cela empêche l’utilisateur de connaître l’état réel des autorisations, cela pourrait même relever d’un CVE
  • C’est un cas où les procédures de sécurité formelles d’Apple entrent en conflit avec la structure réelle d’accès aux fichiers. Il faudrait afficher clairement l’état des autorisations dans les réglages, rendre plus difficile une nouvelle attribution après révocation, et arrêter enfin d’exiger un redémarrage d’app pour certains droits

• Même les versions récentes de macOS ont une confusion similaire dans l’interface de sécurité.
  Dans la section « Full Disk Access », certaines apps apparaissent en grisé, sans qu’on puisse distinguer si elles sont activées ou désactivées.
  Impossible de savoir si c’est un bug ou si l’autorisation est effectivement accordée

  • L’explication d’Apple est floue. La liste « Files & Folders » ne montre en fait que l’historique des demandes d’autorisation.
    Même en désactivant Full Disk Access, seuls certains dossiers sensibles sont protégés, tandis que les dossiers ordinaires (Desktop, Documents, etc.) restent accessibles (documentation Apple)

• L’origine du problème vient de l’attribut étendu com.apple.macl défini sur le dossier Documents. Il est impossible de le supprimer à cause de SIP

  • Ce n’est pas un bug, mais un décalage d’interface entre deux systèmes de sécurité. La protection réelle fonctionne, mais l’interface ne parvient pas à la représenter

• Je me demande si le même phénomène existe sur iOS

  • Non, car sur iOS, une app ne peut pas accéder en dehors du sélecteur de fichiers ou de son propre dossier, donc le même problème ne se produit pas