Prozesse in einer Sandbox laufen lassen [prontosystems.org]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
[[:mac|{{ :Apple.png?40|}}]]
===== Prozesse in einer Sandbox laufen lassen =====

Mit Mac OS 10.5 (Leopard) hat Apple das Sandbox System in Mac OS eingeführt. <fc #008000>Sandboxing</fc> heisst, dass einem Prozess bestimmte Aktionen verweigert werden. Dazu gehört der Dateizugriff oder der Netzwerkzugriff bzw. die Möglichkeit, andere Programme zu starten. Zuständig für das Sandboxing ist die Kernel Erweiterung <fc #008000>Sandbox.kext</fc>. Es gibt mehrere Profile, die den Zugriff auf bestimmte Resourcen verweigern:

  * <fc #008000>**kSBXProfileNoInternet:**</fc> Verbietet den Zugriff auf das netzwerk mit TCP/IP
  * <fc #008000>**kSBXProfileNoNetwork:**</fc> Verbietet den Zugriff auf die Netzwerk Sockets
  * <fc #008000>**kSBXProfileNoWrite:**</fc> Verbietet den Schreibzugriff auf das Dateisystem
  * <fc #008000>**kSBXProfileNoWriteExceptTemporary:**</fc> Lässt den Schreibzugriff nur in /var/tmp und anderen definierten temp-Verzeichnissen zu
  * <fc #008000>**kSBXProfilePureComputation:**</fc> Es sind nur Berechnungen erlaubt, jede Betriebsystem Funktion ist untersagt

Es gibt bereits mehrere System Programme, die in einer Sandbox laufen. Dazu gehören zB <fc #008000>quicklookd</fc>, <fc #008000>named</fc>, <fc #008000>ntpd</fc>, <fc #008000>sshd</fc>, <fc #008000>syslogd</fc> etc. In <fc #008000>/usr/share/sandbox</fc> findet man einige Konfigurationsprofile für die og Sandbox Prozesse. Wird ein Prozess in einer Sandbox gestartet, werden alle seine Kindprozesse ebenfalls in der selben Sandbox gestartet. Mit dem Kommando <fc #008000>sandbox-exec</fc> kann man einen Prozess in einer Sandfbox starten, mit der Option <fc #008000>-f</fc> kann eine Konfigurationsdatei als Grundlage verwendet werden. Man kann sich aber auch selber Konfigurationsdateien erstellen. Meine Konfigurationsdatei ist erstmal recht simpel aber zum demonstrieren reicht es:

<code bash|/usr/share/sandbox/org.prontosystems.nonetwork.sb> (version 1)

;; Erlaube zunächst alles
(allow default) 

;; Verbiete Netzwerkzugriff
(deny network*) 
</code>

Mit dieser Konfigurationsdatei kann ich jetzt eine Shell starten, die keinen Zugriff auf das Netzwerk hat.

<xterm2>$ <fc #008000>sandbox-exec -f /usr/share/sandbox/org.prontosystems.nonetwork.sb /bin/bash</fc>
bash-3.2$ <fc #008000>ping -c 1 localhost</fc>
PING localhost (127.0.0.1): 56 data bytes
ping: sendto: <fc #800000>Operation not permitted</fc>
--- localhost ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
</xterm2>

Aber Achtung: Der Zugriff auf bereits eingehängte Netzwerkvolumes ist nach wie vor möglich, da der Zugriff drauf auf den lokalen Mountpoint erfolgt:

<xterm2>bash-3.2$ <fc #008000>cd /Volumes/orgfiles/</fc>
bash-3.2$ <fc #008000>ls</fc> (cr)
CompatibilityPack_Office2007	Office				Streams.zip			streams.exe
Icons				ScreenShot.png			Sun_ODF-Plugin_for_MS_Office	windows.txt
MacData				Streams				fproxy3.png
</xterm2>

Mit einer weiteren Modifikation unseres Profils lässt sich aber auch das verhindern:

<code bash|/usr/share/sandbox/org.prontosystems.nonetwork.sb> (version 1)

;; Erlaube zunächst alles
(allow default)

;; Verbiete Netzwerkzugriff
(deny network*)

;; Verbiete das lesen und Schreiben in /Volumes
(deny file-read* file-write*
      (subpath "/Volumes"))
</code>

<xterm2>$ <fc #008000>sandbox-exec -f /usr/share/sandbox/org.prontosystems.nonetwork.sb /bin/bash</fc> (cr)
bash-3.2$ <fc #008000>cd /Volumes/orgfiles</fc> (cr)
cd: error retrieving current directory: getcwd: <fc #800000>cannot access parent directories: Operation not permitted</fc>
</xterm2>

Natürlich ist eine "allow default" Regel unbefriedigend, zu gross ist die Gefahr, dass beim Schliessen bzw. Verbieten der gewünschten Aktionen etwas übersehen wird. Demnach stellt eine "deny default" Regel, gefolgt durch diverse allow Regeln, welche den Zugriff auf das System Stück für Stück erlauben, eine wesentlich höhere Sicherheit dar. Hier ein Beispielprofil, welche einer Shell zwar erlaubt im gesamten Filesystem zu lesen aber schreibenden Zugriff nur im tmp-Verzeichnis erlaubt:

<code bash|/usr/share/sandbox/org.prontosystems.allowtmp.sb>(version 1)

;; Verbiete erstmal alles
(deny default)
(debug deny)

;; Erlaube Programme zu starten
(allow process-exec)

;; Erlaube Kindprozesse zu starten
(allow process-fork)

;; Erlaube das Lesen im gesamten Filesystem
(allow file-read*)

;; Erlaube das Schreiben nur in /tmp
(allow file-write*
	(regex #"^/private/tmp($|/)"))
</code>

<xterm2>$ <fc #008000>sandbox-exec -f /usr/share/sandbox/org.prontosystems.allowtmp.sb /bin/bash</fc>
bash-3.2$ <fc #008000>ping -c 1 wiki.prontosystems.org</fc>
<fc #800000>could not lookup DNS configuration info service: (ipc/send) invalid destination port
ping: cannot resolve wiki.prontosystems.org: Unknown host</fc>
</xterm2>
<xterm2>bash-3.2$ <fc #008000>touch /tmp/test.txt</fc>
bash-3.2$ <fc #008000>rm /tmp/test.txt</fc>
bash-3.2$ <fc #008000>touch ~/Desktop/test.txt</fc>
touch: /Users/pronto/Desktop/test.txt: <fc #800000>Operation not permitted</fc>
</xterm2>

Man sieht, es ist kein Netzwerkzugriff möglich; das Anlegen und Löschen einer Datei in /tmp ist möglich; das Anlegen einer Datei auf dem Desktop hingegen nicht.

 --- //pronto 2010/05/27 20:57//

{{keywords>kSBXProfileNoInternet kSBXProfileNoNetwork kSBXProfileNoWrite kSBXProfileNoWriteExceptTemporary kSBXProfilePureComputation}}