Warum man den Privacy-&-Security-Einstellungen von macOS nicht vertrauen kann

• Es wurde ein Problem festgestellt, bei dem die Privacy-&-Security-Einstellungen von macOS den tatsächlichen Status von Zugriffsrechten nicht korrekt widerspiegeln
• Selbst wenn der Zugriff auf den Ordner Documents blockiert ist, kann die App Insent weiterhin Dateien lesen
• Wenn der Benutzer den Ordner direkt auswählt, betrachtet das TCC-System dies als beabsichtigten Zugriff und hebt die Beschränkung auf
• Im Einstellungsfenster wird der Zugriff weiterhin als blockiert angezeigt, tatsächlich sind die Sandbox-Beschränkungen jedoch aufgehoben und der Zugriff bleibt erlaubt
• Um den Zugriff vollständig zu blockieren, sind ein Terminal-Befehl und ein Neustart erforderlich, was das Risiko birgt, dass Nutzer die Kontrolle verlieren

---

Zuverlässigkeitsproblem der macOS-Privacy-&-Security-Einstellungen

• Es wurde ein Fall bestätigt, in dem die macOS-Privacy-&-Security-Einstellungen den tatsächlichen Status von Zugriffsrechten nicht korrekt widerspiegeln
  • Mit einer einfachen App namens Insent trat das Phänomen auf, dass der Zugriff auf den Ordner Documents trotz blockierter Einstellung tatsächlich möglich war
  • Das Problem lässt sich auch auf macOS-Versionen ab 13.5 identisch reproduzieren

• Funktionsweise der App Insent

  • Die Schaltfläche Open by consent öffnet mit Zustimmung des Benutzers eine beliebige Textdatei im Ordner Documents und zeigt sie an
  • Die Schaltfläche Open from folder öffnet Dateien im ausgewählten Ordner und zeigt sie an, wenn der Benutzer den Ordner direkt auswählt
  • Im zweiten Fall wird die Absicht (intent) des Benutzers als Zugriffsfreigabe gewertet, sodass das TCC-System (Transparency, Consent, and Control) den Zugriff ohne zusätzliche Zustimmung erlaubt

• Versuchsablauf und Ergebnisse

  • Zunächst wurde bestätigt, dass Insent Dateien normal lesen kann, nachdem der Zugriff auf Documents erlaubt wurde
  • Danach wurde der Documents-Zugriff von Insent in den Privacy-&-Security-Einstellungen deaktiviert, woraufhin der Zugriff blockiert war
  • Wird Documents jedoch über Open from folder ausgewählt, ist der Zugriff wieder möglich, und danach funktioniert auch Open by consent wieder ohne Einschränkungen
  • Im Einstellungsfenster wird der Zugriff weiterhin als blockiert angezeigt, tatsächlich kann Insent aber weiterhin auf den Ordner Documents zugreifen
  • Um den Zugriff vollständig zu blockieren, muss der Befehl tccutil reset All co.eclecticlight.Insent ausgeführt und der Mac neu gestartet werden

• Analyse des internen Ablaufs

  • Insent ist eine normal notarized App und verwendet weder Sandbox noch besondere Berechtigungen
  • Bei aktiviertem System Integrity Protection (SIP) werden einige Vorgänge in der Sandbox verarbeitet
  • sandboxd fängt Dateizugriffsanfragen ab und sendet an TCC eine Anfrage zur Genehmigung; bei Zustimmung des Benutzers wird der Zugriff erlaubt
  • Nachdem der Zugriff deaktiviert wurde, verweigert TCC ihn zwar, aber sobald der Benutzer den Ordner über das Open/Save-Panel auswählt, fängt sandboxd die Anfrage nicht mehr ab
  • Dadurch kann TCC den Zugriff nicht mehr steuern, und der Zugriff auf den Ordner ist möglich, weil die Sandbox-Beschränkung aufgehoben ist

• Ursache des Problems

  • Wenn ein Zugriff entsprechend der Benutzerabsicht erfolgt, wird die Sandbox-Beschränkung für diesen Ordner entfernt
  • Diese Änderung wird nicht in der UI der Privacy-&-Security-Einstellungen angezeigt, sodass es zwar so aussieht, als sei der Zugriff blockiert, tatsächlich bleibt er jedoch erlaubt
  • Andere geschützte Ordner (z. B. Desktop, Downloads) funktionieren normal; das Problem tritt unabhängig pro Ordner auf

• Fazit

  • Die Anzeige von Zugriffsbeschränkungen im Bereich Files & Folders ist hinsichtlich des tatsächlich angewendeten Status nicht vertrauenswürdig

    • Selbst wenn eine App nicht in der Liste erscheint oder als blockiert angezeigt wird, kann sie in manchen Fällen tatsächlich auf geschützte Ordner zugreifen
    • Wurde ein Zugriffsrecht einmal gewährt, lässt es sich ohne Terminal-Befehl und Neustart nicht aufheben, was das Risiko birgt, dass Nutzer die Kontrolle über die Zugriffskontrolle verlieren

• Zusätzliche Diskussion (Zusammenfassung der Kommentare)

  • Nach dem Experiment wurde vermutet, dass dem Ordner Documents das erweiterte Attribut com.apple.macl hinzugefügt wurde und dieses den Zugriff von Insent erlaubt
  • Der Befehl tccutil reset entfernt zwar die macl-Einträge aus der Datenbank, aber xattr (erweiterte Attribute) können bestehen bleiben, sodass der Zugriff erhalten bleibt
  • Bei aktiviertem SIP ist es schwierig, dieses Attribut zu entfernen; möglich ist das nur im Recovery-Modus mit dem Befehl xattr -d com.apple.macl path/to/Documents
  • Dadurch befinden sich Benutzer in einer Situation, in der sie den tatsächlichen Zugriffsstatus einer App nur schwer prüfen oder kontrollieren können

[GN⁺]

Hacker-News-Kommentare

• Für mich wirkt das wie ein simples Problem. Wenn man einer App Ordnerzugriff gibt, würde ich selbstverständlich erwarten, dass sie auch auf die Dateien in diesem Ordner zugreifen kann

  • Man muss die Dokumentation genau lesen. Die Files & Folders-Einstellungen spiegeln den tatsächlichen Berechtigungsstatus nicht korrekt wider. In der UI sieht es so aus, als wäre der Zugriff blockiert, aber die App kann weiterhin uneingeschränkt auf den Documents-Ordner zugreifen
  • Der Kernpunkt ist: „Man hat die Berechtigung erteilt, dann in der UI wieder entzogen, und trotzdem ist der Zugriff weiterhin möglich“
  • Gleich am Anfang des Artikels steht auch ausdrücklich, dass „die Sicherheitseinstellungen den tatsächlichen Zugriffsstatus einer App falsch darstellen können“
  • Ich hätte erwartet, dass macOS bereits über die UI verknüpfte Ordner erkennt und das im Backend entsprechend abbildet, aber stattdessen wird es nur als einfache Pfadausnahme behandelt, wodurch die UI deaktiviert wird. So etwas hätte ich wohl als Feedback-Report eingereicht. Der Autor befasst sich häufig mit Gatekeeper- oder TCC-Problemen, daher kann ich das nachvollziehen
  • Der Artikel ist zu unklar geschrieben. Es wird nicht ausreichend erklärt, welcher Mechanismus den Zugriff nach dem Entzug der Berechtigung weiterhin bestehen lässt

• Nachdem ich den Artikel gelesen hatte, habe ich alle Ordnerberechtigungen entfernt und getestet, und Insent konnte Documents lesen, obwohl in der UI „None“ angezeigt wurde. Das wirkt wie ein Transparenzversagen

  • Da fragt man sich, ob eine App nicht standardmäßig Zugriff auf das Home-Verzeichnis des Nutzers hat

• Das ist die Ironie eines GUI-zentrierten OS. Um den Zugriff auf den Documents-Ordner vollständig zu blockieren, muss man im Terminal
  tccutil reset All co.eclecticlight.Insent
  ausführen und neu starten

  • Davon würde Jobs sich im Grab umdrehen. Angeblich gab es schon zu NeXT-Zeiten viele solcher Konflikte zwischen GUI und CLI
  • Es gibt auch andere seltsame GUI-Effekte. Ich hatte Wi‑Fi vor dem Herunterfahren deaktiviert, aber nach dem Booten beim Login sah es so aus, als würde das Wi‑Fi-Symbol kurz aktiv erscheinen und dann wieder in den deaktivierten Zustand zurückkehren. Ich weiß nicht, ob das nur ein UI-Bug ist oder ob es tatsächlich kurz eingeschaltet wird

• Der Titel sollte eher zu „macOS-Apps behalten Ordnerzugriff, selbst wenn der Nutzer den Zugriff entzieht“ geändert werden

  • Tatsächlich hat der Nutzer aber keinen spezifischen Zugriff entzogen, sondern nur den allgemeinen Ordnerzugriff. Es gibt keine Möglichkeit, feinere Zugriffe einzeln zu entziehen

• Das Sandbox-System des Mac erinnert mich an die Windows-UAC. Eine Struktur, die nur die Ermüdung der Nutzer verstärkt.
  Ich halte den optionalen Container-Ansatz von *nix für deutlich besser.
  Besonders seltsam ist, dass im Terminal gestartete Hintergrundprozesse ihre Berechtigungen behalten, selbst wenn der Elternprozess beendet wurde. Das ganze Berechtigungssystem wirkt dadurch eher formalistisch

  • Apple sollte sich seine alten Werbespots noch einmal ansehen (YouTube-Link)
  • Zur Einordnung: UAC ist keine Sicherheitsgrenze, daher werden UAC-Bypässe nicht als Privilege-Escalation-Schwachstellen behandelt
  • Das größere Problem ist, dass immer noch viele Entwickler in dem veralteten Paradigma feststecken, dass „alles auf alles zugreifen kann“. Die UX von macOS ist nicht perfekt, aber unbegrenzter Zugriff als Standard ist noch riskanter
  • Außerdem macht Apple Ausnahmen für die eigenen Apps. Das dient der Schonung der User Experience
  • Das ist nicht die Sandbox des Mac, sondern das TCC-System. Apps, die App Sandbox verwenden, können nicht einmal einen Prompt für den Documents-Zugriff anzeigen. Stattdessen können sie den Zugriff über Security Scoped Bookmarks erhalten (Referenzlink)

• Neben tccutil reset kann man auch zurücksetzen, indem man in den Sicherheitseinstellungen die Berechtigung einschaltet und wieder ausschaltet.
  Die UI zeigt den Status wegen eines Bugs nur falsch an, die tatsächlichen Berechtigungen funktionieren normal.
  Auch die Farbe der Checkboxen ändert sich je nach Fokus und sorgt für Verwirrung. Das ist selbst in der Sequoia-Version noch so.
  Interessant ist auch, dass auf externen Laufwerken installierte Spiele Zugriff auf „removable volumes“ anfordern und dadurch massenhaft in der Liste auftauchen

• Ich bin unsicher, ob das ein Bug, eine Sicherheitslücke oder nur ein Versehen ist. Ich überlege, ob es sinnvoll wäre, für alle Apps den Reset-Befehl auszuführen

  • Es ist einfach ein Versäumnis in der UI. Das interne System funktioniert normal
  • So etwas wird als Security-UI-Bug eingeordnet. Weil der Nutzer den Berechtigungsstatus nicht zuverlässig erkennen kann, könnte es sogar ein Fall für eine CVE sein
  • Das ist ein Beispiel dafür, wie Apples formalisierte Sicherheitsprozesse mit der realen Struktur des Dateizugriffs kollidieren. In den Einstellungen sollte der Berechtigungsstatus klar angezeigt werden, und nach einem Entzug sollte eine erneute Erteilung nicht zu leicht sein. Und Berechtigungen, die einen App-Neustart verlangen, sollten langsam ganz verschwinden

• Auch in aktuellen macOS-Versionen gibt es ähnliche Verwirrung in der Security-UI.
  Im Bereich „Full Disk Access“ werden manche Apps grau dargestellt, aber man kann nicht erkennen, ob das „ein“ oder „aus“ bedeutet.
  Es ist unklar, ob das ein Bug ist oder ob die Berechtigung tatsächlich besteht

  • Apples Erklärung ist vage. Die Liste unter „Files & Folders“ zeigt offenbar nur den Verlauf von Berechtigungsanfragen an.
    Selbst wenn Full Disk Access deaktiviert ist, werden nur einige sensible Ordner geschützt, während normale Ordner (Desktop, Documents usw.) weiterhin zugänglich bleiben (Apple-Dokument)

• Die Ursache des Problems ist das für den Documents-Ordner gesetzte erweiterte Attribut com.apple.macl. Wegen SIP lässt es sich nicht entfernen

  • Das ist kein Bug, sondern eine UI-Diskrepanz zwischen zwei Sicherheitssystemen. Der tatsächliche Schutz funktioniert, aber die UI kann ihn nicht korrekt darstellen

• Ich frage mich, ob es auf iOS dasselbe Phänomen gibt

  • Unter iOS können Apps nicht außerhalb des Dateiauswahldialogs oder ihres eigenen Ordners auf Dateien zugreifen, daher tritt dasselbe Problem dort nicht auf