Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Dateizugriff in macOS: Versteckte Zugriffsrechte auf Ordner

Die Zugriffskontrollen unter macOS werden zunehmend konsequenter umgesetzt: Bevor Apps auf Dateien, Ordner, Kontakte oder den Ort zugreifen dürfen, müssen sie mindestens einmal um Erlaubnis bitten. In den Systemeinstellungen unter „Datenschutz & Sicherheit“ finden Anwender diese Berechtigungen und können diese einer App wieder entziehen. „Transparency, Consent & Control“ (TCC) nennt Apple dies. Doch was Dateien und Ordner angeht, klaffen Lücken im feinmaschigen Netz der Zugangsberechtigungen, berichtet Howard Oakley.


Bevor eine frisch installierte App Dateien beispielsweise im Dokumente- oder Downloads-Ordner öffnen oder ablegen kann, muss sie die Zustimmung des Nutzers (Consent) einfordern: Ein Dialog fragt den Anwender, ob er dies gewährt oder nicht. Danach darf sich diese App im Ordner umsehen, Dateien öffnen und neue anlegen. Gleichzeitig entsteht in den Systemeinstellungen unter Datenschutz & Sicherheit/Dateien & Ordner ein neuer Eintrag mit dem Namen der App und dem jeweiligen Ordner. Schaltet man den Zugriff wieder ab, kann die App keine Dateien von dort mehr öffnen.

Ausnahme via „Öffnen“-Dialog
Wer stattdessen den Öffnen-Dialog bemüht und einer App einmalig Zugriff auf einen Ordner gewährt, erhält die jeweilige App ein dauerhaftes Leserecht für den ausgewählten Ordner – und dieser ist unabhängig von dem Dialog in den Systemeinstellungen. Mehr noch: Auf welche Ordner eine App dank dieser Regelung zugreifen kann, lässt sich in der grafischen Bedienoberfläche weder einsehen noch löschen.

Insent hat laut Systemeinstellungen keinen Zugriff auf den Dokumentordner – und kann darin doch Dateien lesen und schreiben.

App zum Experimentieren
Um diesem Phänomen auf die Spur zu kommen, schrieb Oakley die Software Insent. Sie fordert Dateizugriffe an und versucht dann, Textdateien zu lesen oder zu schreiben. Bisher konnte er nur einen Weg finden, sämtliche Ordnerzugriffe seiner App zu entfernen – und dieser setzt einen Terminal-Befehl mit anschließendem Neustart voraus:

tccutil reset All co.eclecticlight.Insent

In den (Ordner-)Attributen versteckt
In den Nutzerkommentaren offenbart sich eine mögliche Antwort: Höchstwahrscheinlich speichert macOS die Zugriffserlaubnis in den erweiterten Attributen (xattr) des jeweiligen Ordners. Im Eintrag „com.apple.macl“ scheint dies in Binärform gespeichert zu werden. Oakley sieht aufgrund der komplexen Gestaltung keine bedeutende Sicherheitslücke, aber wundert sich über die mangelnde Transparenz – zusammen mit dem komplizierten Weg, diese Einstellung zurückzusetzen. Möglicherweise betrachtet Apple dieses Phänomen als bedauernswerte Randerscheinung der offeneren Struktur von macOS: Das beschriebene Verhalten gilt für Programme, welche ohne Sandbox gestaltet sind; solche lässt Apple im App Store gar nicht zu.

Was ist geschützt?
In weiteren Experimenten versuchte Oakley herauszufinden, welche Ordner überhaupt eine Consent-Abfrage auslösen. Bisher fand er sechs Orte: Schreibtisch, Dokumente, Downloads, Cloud-Ordner, Netzwerkordner und auswerfbare Volumes – letztere allerdings nur, wenn sie nicht schon beim Hochfahren angemeldet wurden. Das bedeutet wiederum, dass die Ordner „Bilder“ und „Filme“ anscheinend nicht vom TCC-Mechanismus geschützt werden – ebenso wenig eigene im Benutzer-Ordner angelegte Ordner.

Kommentare

Perry Goldsmith
Perry Goldsmith15.04.26 18:38
Das Wort "stringent" bedeutet nicht das, was der Autor denkt.
+8
ttwm15.04.26 19:13
Perry Goldsmith
Das Wort "stringent" bedeutet nicht das, was der Autor denkt.
Behauptung aufgestellt. Begründung und Beweis fehlt…
-12
UWS15.04.26 19:33
ttwm
Behauptung aufgestellt. Begründung und Beweis fehlt…
Demnächst muss man hier wohl beweisen welcher Tag morgen ist, die einfache Nennung reicht dann nicht mehr...Junge, Junge...

Das Wort stringent ist im obigen Zusammenhang falsch verwendet. Keine Ahnung, was der Autor damit ausdrücken will. Im Sinne von "strenger" ist es das falsche Wort. Im Sinne von inkonstistent oder unlogisch auch, da wäre stringent das genaue Gegenteil.

Und da ich's gerne transparent halte: Einen Daumen rauf für Perry und – damit das stringent bleibt – einen runter für ttwm.
There is no cloud…it’s just someone else’s computer.
+10
ttwm15.04.26 20:00
UWS
ttwm
Behauptung aufgestellt. Begründung und Beweis fehlt…
Demnächst muss man hier wohl beweisen welcher Tag morgen ist, die einfache Nennung reicht dann nicht mehr...Junge, Junge...
Nein, das muss man nicht. Aber etwas "hinrotzen" ohne Begründung sieht danach aus, dass man darauf hofft, das weitere Teilnehmer die entsprechende Begründung liefern. So wie Du es jetzt gemacht hast…
-9
UWS15.04.26 20:34
ttwm
Aber etwas "hinrotzen" ohne Begründung sieht danach aus, dass man darauf hofft, das weitere Teilnehmer die entsprechende Begründung liefern
…bei etwas komplexeren Sachverhalten stimme ich dir da ausdrücklich zu…aber doch nicht bei einem allgemein verständlichen Wort, das einfach nur falsch benutzt wurde.

Transparenzhinweis: Das Minus unter deinem zweiten Post ist diesmal nicht von mir.
There is no cloud…it’s just someone else’s computer.
+5
RichMcTcNs15.04.26 22:51
Hallo,
was ist denn hier los?

Stringent ist ja wohl in der Tat hier nicht richtig. Wer das nicht weiß, guckt einfach ins Lexikon. Das geht mit Markieren, Wählen, Drücken.
Das anzumerken muss nicht sein, iist aber doch kein Problem.

Oder darf ich hier nur noch Worte benutzen, die alle kennen? Und wer ist alle? Und wie stell ich das sicher? Leute!
+4
immo_j
immo_j15.04.26 23:07
Perry Goldsmith
Das Wort "stringent" bedeutet nicht das, was der Autor denkt.
Bevor die Kommentarfunktion überhitzt, ersetze ich "stringenter" durch "konsequenter durchgesetzt". Ich hoffe, dies erweist sich als stringentere (im Sinne von "eindeutigere, schlüssigere") Formulierung.
Allerseits einen schönen Abend!
+9
t.stark
t.stark16.04.26 08:30
Das Thema Berechtigungen ist wirklich unnötig komplex. Da fehlt mir der Apple-Weg.
+1
Legoman
Legoman16.04.26 08:49
Manchmal sind die Diskussionen hier wirklich anstringent.
+4
UWS16.04.26 09:40
Um doch mal etwas Inhaltliches beizutragen...

Der beschriebene Hybridbetrieb (mit und ohne Sandboxing) mit seinen Auswirkungen wird einerseits eben nichts anderes zulassen, ist aber andererseits für viele Programm einfach zwingend. So gut die Sicherheit eines Sandbox-Konzeptes für den Normalo-Anwender auch sein mag, für bestimmte Anwendungen (DAWs zum Beispiel) ist das nicht so einfach umzusetzen.

Man greift ja im Regelfall auf eine Menge Plug-ins (sprich andere Programme) und Inhalte zurück, mit denen möglichst latenzfrei kommuniziert werden muss. Apple regelt das für Logic Pro mit dem AUHostingService und diversen Techniken - aber eben nur für AU-Plugs nicht für VST.

Selbst Apples eigene Programme Logic Pro oder Final Cut Pro, die ja aus dem – angeblich Sandbox-only – AppStore kommt, gehen in Sachen Sandboxing einen sehr speziellen Weg und nutzen Funktionen, die ein normaler App-Anbieter im Store wohl kaum genehmigt bekommen dürfte.

Theoretisch könnten Anbieter wie Steinberg oder Ableton sicher auch eine Sandbox-ready Konstruktion anbieten, ich denke aber mal, dass der Aufwand dafür immens und damit unwirtschaftlich ist. Zudem müssen andere Software-Hersteller ja zusätzlich auf Plattform-Kompatibilität achten und optimieren.

Sollte Apple wirklich mal die Sandbox-Daumenschrauben konsequent anziehen, wird's vermutlich bitter.
There is no cloud…it’s just someone else’s computer.
+2
Wellenbrett16.04.26 10:47
Danke für den interessanten Artikel!
Die Komplexität der Zugriffsmechanismem nimmt zu, die Transparenz und Dokumentation von Apple nimmt ab. Ich teile mal meine persönliche Zusammenfassung der Zugriffsmechanismen. Bei den Zugriffsmechanismen unter 2) wird der Zugriff über die Benutzer-ID geregelt, bei 3) über die App-Signatur:
1) SIP
2) Posix-Zugriffsrechte und Access Controll Lists (ACLs)
2.1) Beachtung von Zugriffsrechten auf externem Volume aktiviert/deaktiviert
3) Transparency, Consent & Control (TCC) mit laut Oakley wahrscheinlichen xattr-Einfluß
3.1) Wurde einer App Festplattenvollzugriff gewährt/nicht gewährt

Mir ist unklar, warum Apple so intransparent mit der TCC-Funktion umgeht. Falls Apple das nicht dokumentiert, um damit Angriffe zu erschweren, habe ich Zweifel, ob das der richtige Weg ist.
Mir erscheint auch die Begrenzung von TCC auf bestimmte Verzeichnisse des Benutzerordner des internen Volumes etwas willkürlich. Beispielweise wird ~/Downloads durch TCC geschützt, ~/Pictures aber nicht. Selbst angelegte Verzeichnisse auf einem externen lokalen Volume kann ich zwar durch Unix-Zugriffsrechte und ACLs vor dem Zugriff durch andere Nutzer schützen (macht bei einem Mehrbenutzersystem ja Sinn), aber nicht durch TCC (granular auf einzelne Verzeichisse beschränkt) quasi vor mir selbst, wenn ich eine bösartige App starte.
+2

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.