Wie sandbox deaktivieren?

[thorstenhirsch]

Hallo. In meiner /var/log/system.log tauchen seit 10.11 immer wieder solche Einträge auf:

Dec 26 23:49:40 meinrechner kernel[0]: Sandbox: softwareupdated(331) deny(1) system-fsctl 682f
Dec 26 23:51:48 meinrechner sandboxd[168] ([331]): softwareupdated(331) deny system-fsctl 0x682f

Verbietet die sandbox von OS X dem eigenen Updater einige fsctl-Aufrufe? Warum?!

Noch ein Beispiel: Ich hab' htop per homebrew installiert, aber immer wenn ich es starte, bekomme ich rund 500 Einträge in dmesg und /var/log/system.log, die wie folgt aussehen:

Sandbox: htop(580) System Policy: allow(0) mach-prig-task-port 579

Hinten der Port wird quasi von 1 bis 579 durchgezählt, einige Nummern fehlen... also rund 500 Einträge. Man beachte: da steht "allow", ich werde also zugespammt mit Meldungen dazu, was sandbox einem Programm erlaubt?! Das ist ja noch schlimmer!

Wenn ich das richtig sehe, kann ich die deny-Meldungen "bekämpfen", indem ich ein sandbox-profile anlege. Zu den allow-Meldungen ist mir noch nichts eingefallen. Aber darauf will ich eigentlich gar nicht hinaus. Mir geht's um das prinzipielle Konstrukt der sandbox in einem System wie OS X. So eine sandbox mit Berechtigungen auf einzelnen "Apps" mag ja die richtige Herangehensweise auf einem System sein, zu dem man kein Vertrauen hat. Ich hab' aber Vertrauen zu OS X und dem Zeug, das ich installiere. Ich will diesen sandbox-Krempel deaktivieren! Bislang habe ich rootless deaktiviert (im recovery mode)...

csrutil disable

Aber das reicht offensichtlich noch nicht. Ich bekomme nach wie vor die 500 Sandbox-Meldungen in dmesg und /var/log/system.log. Was fehlt noch?

 

[TEXnician]

Sandbox kannst du nicht deaktivieren, das kann nur der Entwickler bzw. der Entwickler entscheidet, ob eine Programm (oder ein Teil davon) in einer Sandbox laufen soll und was das jeweilige Programm dort machen darf.

Über das Terminal kann man mit dem Befehl "sandbox-exec" ein Programm in einer Sandbox startet, die man beispielsweise mit einer profil-Datei konfigurieren kann. Das hindert das Programm aber keinesfalls daran, Programmteile in einer weiteren Sandbox zu starten.

Sinn und Zweck des ganzen ist der Schutz vor Malware. Sollte nämlich ein Programm einen Fehler enthalten, der es ermöglicht Schadcode einzuschleusen (vom verseuchten Word-Dokument bis hin zum "Sicherheitsloch" Flash-Player gibt es genügend Beispiele) und auszuführen, kann dieser Schadcode weniger Schäden anrichten, wenn er nur das darf, was ihm eine Sandbox erlaubt, als wenn er direkt alle Rechte des Benutzers hat. Bei einer gut konfigurierten Sandbox müsste der Schadcodeschreiber also zusätzlich noch Schwachstellen in der Sandbox-Implementierung kennen und ausnutzen, damit sein Code vernünftig läuft.

Und Rootless zu deaktivieren ist keine gute Idee, denn bei der normalen Arbeit sollte kein Benutzer/Administrator System-Dateien ändern müssen. Umgekehrt kann Schadcode, der System-Dateien ändern kann/darf, sich in den System-Dateien verewigen und so auch jedweden Sicherheitsmechanismus/Kontrolle umgehen.