macOS Catalina: Festplattenvollzugriff

Meine, ganz offiziell, extrem subjektive Meinung:

1. Kiste platt machen.
2. KEINE "Helferlein" installieren (dazu gehört unnötige Antivirensoftware).
3. Sich an einem funktionierenden, wie verwandelten Rechner erfreuen.
 
Zitieren
  • Gefällt mir
Reaktionen: Kibitz, bernie313 und dg2rbf
apple hat dieses konzept, wie soviele andere, ja überhaupt nicht fertig durchdacht.

terminal starten find über die ganze platte jagen und alle anfragen bzgl. zugriff kommen für terminal anstatt find. womit in einem terminal fenster jeder prozess dann zugriff auf die jeweiligen freischaltungen hätte. will man das so? nein kann man es verhindern? scheinbar nicht ausser man sperrt das terminal und gibt nur immer wieder händisch frei.
 
MOM2006 schrieb:
apple hat dieses konzept, wie soviele andere, ja überhaupt nicht fertig durchdacht.

terminal starten find über die ganze platte jagen und alle anfragen bzgl. zugriff kommen für terminal anstatt find. womit in einem terminal fenster jeder prozess dann zugriff auf die jeweiligen freischaltungen hätte. will man das so? nein kann man es verhindern? scheinbar nicht ausser man sperrt das terminal und gibt nur immer wieder händisch frei.
Zum Vergrößern anklicken....
Was stellst du dir dann vor? Willst du etwa jedes einzelne Tool aus /usr/bin dann einzeln freigeben?
 
MOM2006 schrieb:
klar wenn dann richtig. ich möchte bspw. nicht, dass scp bestimmte bereiche anfassen darf.
Zum Vergrößern anklicken....

:D ... schlechtes Beispiel.

Wenn du scp nutzt, machst du das lokal und da macht es eigentlich wenig Sinn, dass du einen Befehl den du aktiv nutzen willst, indem du ihn eintippst, gleichzeitig gesperrt haben willst.

Auf der remote-Seite musst du nicht scp oder Terminal.app berechtigen, sondern sshd.

;)
 
lisanet schrieb:
:D ... schlechtes Beispiel.

Wenn du scp nutzt, machst du das lokal und da macht es eigentlich wenig Sinn, dass du einen Befehl den du aktiv nutzen willst, indem du ihn eintippst, gleichzeitig gesperrt haben willst.

Auf der remote-Seite musst du nicht scp oder Terminal.app berechtigen, sondern sshd.

;)
Zum Vergrößern anklicken....

wenn mir malware per scp dateien von local nach remote kopieren will, dann wird der remote sshd das wohl weniger sperren. ich möchte scp auf bestimmten location benutzen, aber sicher nicht für kontakte, kalender etc. denn auch das kann fernab vom vollständigen festplattenzugriff noch eingeschränkt werden. war aber jetzt nur ein beispiel, vielleicht nicht das beste, weil apple da wohl eher das sh anstatt dem scp anzeigen würde.
 
MOM2006 schrieb:
wenn mir malware per scp dateien von local nach remote kopieren will, dann wird der remote sshd das wohl weniger sperren.
Zum Vergrößern anklicken....

In diesem Fall würde die Malware wohl kaum erst Terminal.app öffnen, sondern das wohl im Hintergrund per Direktaufruf oder Start eines Skriptes versuchen. In diesem Fall würde dann die Berechtigung für scp selbst oder für die genutzte Shell erforderlich sein. Das wäre dann so, wie du es ursprünglich wolltest.

MOM2006 schrieb:
ich möchte scp auf bestimmten location benutzen, aber sicher nicht für kontakte, kalender etc. denn auch das kann fernab vom vollständigen festplattenzugriff noch eingeschränkt werden. war aber jetzt nur ein beispiel, vielleicht nicht das beste, weil apple da wohl eher das sh anstatt dem scp anzeigen würde.
Zum Vergrößern anklicken....
Wenn du z.B. einen LaunchAgent als Shellscript erstellst, das scp verwendet, wird als Fehlermeldung angezeigt, das scp keinen Zugriff hat. Es ist also auch hier im Grunde so, wie du es für Terminal.app wolltest.

Nur macht es halt in Terminal.app weniger Sinn, jeden einzelnen Befehl, den du bewusst eintippst, nochmal extra zu berechtigen. Bei Scriptaufrufen auf anderen Wegen (Malware, launchd) ist das anders.
 
... und als Ergänzung:

würde die Malware das nicht per scp oder Shellscript machen wollen, sondern selbst implementieren, würde die Berechtigung für die Malware selbst nötig werden.
 
Ich versteh das angebliche "Sicherheitsloch" im Fall von Terminal.app nicht. Du ziehst bewusst und gewollt einen Ordner / Datei ins Terminal und möchtest dann aber, dass Terminal keinen Zugriff darauf hat? Finder ist immer berechtigt auf diese Ordner / Datei zuzugreifen.

Wenn du das als "Sicherheitsloch" empfindest, dann müsste ja auch ein Sicherheitsloch sein, dass du mit Finder auch ohne explizite Berechtigung in diese Ordner sehen kannst. Oder willst du auch Finder beschränken? Oder auch bei Kontakte.app oder Kalender.app. Die brauchen auch keine explizite Berechtigung das sie auf Kontakte oder Kalender zugreifen können.
 
solange da nicht explizit schon ein verbot gesetzt kann ich deinen ausführungen folgen. wird aber aus irgendeinem grund der zugriff auf den jeweiligen pfad schon verweigert, sollte zumindest ein hinweis kommen wo der user dann entscheidet ja oder nein. und nicht einfach freigeben. vor allem scheint das so freigegeben zu werden, dass der user das nicht mehr in der gui als freigabe erkennt. sondern nur noch über erweiterte datei ordner attribute, die dann nur noch nach deaktivieren von sip bereinigt werden können.
 
lisanet schrieb:
Ich versteh das angebliche "Sicherheitsloch" im Fall von Terminal.app nicht. Du ziehst bewusst und gewollt einen Ordner / Datei ins Terminal und möchtest dann aber, dass Terminal keinen Zugriff darauf hat? Finder ist immer berechtigt auf diese Ordner / Datei zuzugreifen.

Wenn du das als "Sicherheitsloch" empfindest, dann müsste ja auch ein Sicherheitsloch sein, dass du mit Finder auch ohne explizite Berechtigung in diese Ordner sehen kannst. Oder willst du auch Finder beschränken? Oder auch bei Kontakte.app oder Kalender.app. Die brauchen auch keine explizite Berechtigung das sie auf Kontakte oder Kalender zugreifen können.
Zum Vergrößern anklicken....
Der Vergleich hinkt einfach komplett.
Dem Terminal werden durch das reine reinziehen des Pfades - also praktisch dem reinschauen mit dem Finder - Rechte eingeräumt von denen der Benutzer nichts weiß, die er nicht nachträglich einsehen und/oder löschen kann. Und ab nun kann das Terminal, auch unbewusst/ungewollt gestartet, beliebigen Schindluder mit einem Pfad treiben, von dem der Benutzer immer noch nicht weiß, dass dieser nun "offen" liegt. Und das auch, wenn der Benutzer nur aus versehen mal einen falschen Pfad ins Terminal gezogen hat, den Befehl aber nie abgesetzt.
In deiner Analogie würde das bedeuten, dass nur weil ich einen Ordner mal mit dem Finder angesteuert habe, zukünftig andere Programme "im Hintergrund" beliebiges mit dessen Inhalt machen können und das ist ja so absolut nicht der Fall.


https://lapcatsoftware.com/articles/macl.html schrieb:
It turns out that the com.apple.macl extended attribute is governed by System Integrity Protection, so the only way to delete it is to disable SIP, or boot into another volume and delete it from there. Thus, once you implicitly grant special access to a file, you can't easily revoke that special access.
Zum Vergrößern anklicken....
Das geht halt einfach nich...
Und ich finde dieser Kommentar trifft es einfach auf den Kopf:
https://news.ycombinator.com/item?id=21828115 schrieb:
It's a workaround for the new permissions system in Catalina being a complete mess from the get go. Previously, the Terminal in Catalina would pop up a dialogue asking for permission to access the file you'd just dragged in.

Good security or not, this entire system should not have been rolled out unless/until Apple had a sane UI for handing it. They don't.
Zum Vergrößern anklicken....
 
Zitieren
  • Gefällt mir
Reaktionen: dg2rbf und MOM2006
lisanet schrieb:
Ich versteh das angebliche "Sicherheitsloch" im Fall von Terminal.app nicht. ....
Zum Vergrößern anklicken....
wenn ich als Angreifer böswillig und unauffällig Schaden auf einem BSD, Linux oder Unix anrichten, dann über das Terminal.
Wenn ein Terminal alle Rechte hat ist das nicht weniger als ein Desaster.
 
ok, dass man ein xattr nicht mehr einfach so löschen kann ist strange und darf nicht einfach so passieren.

Und ja, es ist vom Prinzip her gesehen nicht durchgängig stimmig. Ich sehe aber immer noch kein "Sicherheitsrisiko", nirgends.

Du musst in Terminal nach wie vor explizit was eintippen, sudo bleibt weiterhin aktiv, die Unix-Permissions sind ebenso noch exakt genauso da. Wo soll jetzt ein Sicherheitsrisiko bestehen, so wie es heise bzw. der frustrierte Developer (der lt. seiner website ein grundsätzliches Problem mit sandboxing, gehärteter Runtime und co hat) darstellen.
 
das spannende wäre ja ob bei drag and drop von / automatisch auf alles drunterliegende dann auch freigegeben wird oder nur auf den einen pfad ohne weitervererbung auf etwaige unterpfade.
und vor allem ist die frage bei drag and drop wer das xattr setzt mit welchen rechten. kann ja nicht sein, dass ein normaler user account dinge setzen kann, die nur noch nach abschalten von sip wieder rückgängig gemacht werden können. vor allem ein standard user wird sip wohl nie deaktivieren können
 
Kaito schrieb:
dass nur weil ich einen Ordner mal mit dem Finder angesteuert habe, zukünftig andere Programme "im Hintergrund" beliebiges mit dessen Inhalt machen können und das ist ja so absolut nicht der Fall.
Zum Vergrößern anklicken....
und genau das "im Hintergrund" ist eben nicht so. Selbst ein einfaches ls ~/Desktop geht nicht "im Hintergrund", selbst wenn du zuvor den Desktop ins Terminal gezogen hast.

Das war genau das Problem, dass ich vor ein paar Tagen mit einem LaunchDaemon hatte und auch hier im Forum diskutiert wurde.

https://www.macuser.de/threads/catalina-probleme-mit-den-zugriffrechten.839123/

Du kannst das ganz einfach selbst testen, indem du mit der App "LaunchControl" einen Agent erstellst, der lediglich "/bin/ls /Users/deinname/Desktop" ausführt. Er wird mit einem Error 1 scheitern. Wenn du nun in LaunchControl das Jogging aktivierst siehst du: "ls: Desktop: Operation not permitted"

Wo also soll nun das "Sicherheitsrisiko" sein?
 
lisanet schrieb:
Terminal.app hat nicht alle Rechte, auch wenn du's nicht glaubst. Du musst immer noch explizit was eintippen. Terminal.app != Shell.
Zum Vergrößern anklicken....
hat nicht alle Rechte, richtet sich erweiterte Rechte aber ein:
Die Terminal-App von macOS räumt sich in Catalina Spezialrechte ein, die Apples erweiterte Schutzfunktionen umgehen
Zum Vergrößern anklicken....

Nennt man eigentlich privilege escalation und ist ein Bug. Außer bei Apple natürlich.
 
maba_de schrieb:
hat nicht alle Rechte, richtet sich erweiterte Rechte aber ein:


Nennt man eigentlich privilege escalation und ist ein Bug. Außer bei Apple natürlich.
Zum Vergrößern anklicken....
ok, du hast Recht. Das alles ist in Terminal.app ein großes Sicherheitsrisiko und ein Skandal.
 
Zurück
Oben Unten