X

Neuigkeiten, Best Practices, Hinweise auf Events zu Oracle Solaris auf Deutsch.

Named Secure Sandboxes in Oracle Solaris 11.4 Beta

Detlef Drewanz
Master Principal Sales Consultant

Eines der interessantesten neuen Features in Oracle Solaris 11.4 Beta sind die Secure Sandboxes. Wie so oft bei Security Features ist auch das Konzept der Secure Sandboxes relativ komplex. Was steckt also eigentlich dahinter und was kann ich damit machen ? Dieser Blog widmet sich vor allem den Named Secure Sandboxes.

Darren Moffat ist in diesem Blog bereits auf Application Sandboxing mit Oracle Solaris 11.4 eingegangen und schreibt dort vor allem über temporäre Named Sandboxes. In diesem Blog soll es mehr um Named Secure Sandboxes gehen. Aber zunächst brauchen wir ein paar Grundlagen:

Security Sandboxes werden verwendet, um Anwendungen von anderen Prozessen in einem System zu isolieren. Diese Isolation kann in Bezug auf Security und Ressourcen erfolgen. Daraus ergeben sich auch die typischen Anwendungsfälle für Sandboxes:

  • Datenschutz
  • Test von Anwendungen
  • Ablaufumgebung für die Analyse von "bösartigem" Code
  • ... und noch mehr wo es um hochsensitive Umgebungen geht und höchste Abschottung nötig ist

Wikipedia nennt hier einige Beispiele für Sandbox Implementationen. In Oracle Solaris 10 sind Solaris Zones eingeführt worden, die seitdem erheblich weiterentwickelt wurden und sehr vielfältig eingesetzt werden - u.a. auch zum "sandboxing".

Secure Sandboxes in Oracle Solaris 11.4 sind jedoch viel leichtgewichtiger als Solaris Zones. Sie müssen nicht installiert oder gebootet werden und sollten natürlich auch nicht mit einer virtuellen Maschine oder einem Container verglichen werden. Es handelt sich vielmehr um einen isolierten Prozeßbereich im System. Die Implementation der Secure Sandboxes erfolgte in Oracle Solaris vor allem durch Security Labels - eine Technologie, die bereits mit Trusted Solaris eingeführt wurde und die für Oracle Solaris 11 mit den Trusted Extensions weiterentwickelt und die in Oracle Solaris 11.4 um File and Process Labeling erweitert wurde. Eine Secure Sandbox wird insgesamt durch die folgenden Konfigurationen bestimmt:

  • Label - dieser bildet die clearance (siehe weiter unten) für die Prozesse in der Sandbox
  • UID, GID - unter denen die Prozesse in der Sandbox laufen
  • Projekt - jeder Sandbox ist ein Projekt zugeordnet, z.B. um zusätzliche Ressource Controls auf Projektbasis zu definieren

Solaris Security Labels

Für das Verständnis der Secure Sandboxes ist zunächst Verständnis für Solaris Security Labels notwendig. Labels kennzeichnen die Sensitivität von Objekten, z.B. Dateien im Filesystem. Diese Sensitivität hat jedoch nichts mit den Zugriffsrechten im Filesystem zu tun, sondern richtet sich nach weiteren, übergreifenden Kriterien. Labels von Prozessen werden clearance genannt. Dominiert ein Prozeß mit seiner Clearance z.B. einen Security Label einer Datei, kann auf diese Datei zugegriffen werden. Wenn nicht, ist diese Datei z.B. für den Prozeß nicht sichtbar.

Was ist nun genau ein Security Label und wie ist er aufgebaut ?

Ein Security Label besteht aus zwei Teilen - der Klassifizierung(Classification) und dem Einsatzbereich (Compartment).

  • Classification: Die Klassifizierung legt die Hierarchie zum Zugriff auf ein Objekt fest. Diese Hierarchie wird intern durch Werte festgelegt, wobei ein höherer Wert in der Hierarchie oben steht und auf darunterliegende Objekte zugreifen kann. Untere Objekte haben keinen Zugriff auf höhere Objekte. Wenn man also Informationen klassifizieren würde mit: Public(1), Confidential(3), Top Secret(5), so steht "Public" in der Hierarchie unter "Top Secret". Jemand der die Berechtigung hat "Top Secret" Informationen zu lesen, darf auch "Public" oder "Confidential" Information lesen, aber nicht gekehrt.
  • Compartment: Das Compartment bestimmt den Anwendungsbereich für einen Label. Dieser Bereich wird intern durch eine Bitmaske dargestellt. D.h. unterschiedlich gesetzte Bits können unterschiedliche Bereiche identifizieren, aber gemeinsam gesetzte Bits können auch mehrere Bereiche einschließen. Wenn man z.B. in einer Firma die Abteilungen Sales (Bit0), Engineering(Bit1) und Finance(Bit2) hat, so kann man durch Labeling dafür sorgen, dass die einzelnen Abteilungen nur auf ihre Abteilungsinformationen zugreifen können. Aber jemand vom Controlling(Bit0,1,2) könnte auf die Informationen aller Abteilungen zugreifen.
  • Clearance: Die Clearance ist der Prozeßlabel und bestimmt, welche Objekte mit Labeln für diesen Prozeß sichtbar sind. Die Clearance muss in dem Falle den Label dominieren. Eine Clearance mit "Top Secret" + "Controlling" aus dem obigen Beispiel würde einem Prozeß Zugriff auf alle Informationen geben.

Es gibt zwei vordefinierte Label, die nicht verändert werden können:

  • ADMIN_LOW: Das Label wird von jedem anderen Label dominiert.
  • ADMIN_HIGH: Das Label dominiert alle anderen Label.

Anders als bei Trusted Solaris oder den Trusted Extensions, sind Security Labels in Solaris 11.4 immer aktiv. Damit jedoch auch ohne spezielle Konfiguration der Security Labels weiterhin "alles funktioniert", sind die Files in Oracle Solaris ohne Label oder haben den Label ADMIN_LOW. Alle Prozesse haben die Clearance ADMIN_HIGH.

Konfiguration von Sandboxes

Nachdem Darren Moffat in seinem Blog bereits gezeigt hat, wie Application Sandboxes genutzt werden können, soll es hier um Named Security Sandboxes gehen.

Diese müssen vor der Benutzung durch den Administrator konfiguriert werden und können durch den konfigurierten User benutzt werden. Dabei gibt es Parent und Child Sandboxes. Child Sandboxes "erben" die Classification des Parents und variieren den Compartment Teil. Ein Benutzer der Parent Sandbox kann auf seine Child Sandboxes zugreifen, da seine Clearance den Label der Child Sandboxes dominiert. Während für einen Benutzer mehrere, durch unterschiedliche Klassifikationen isolierte, Parent Sandboxes konfiguriert werden können, sind Child Sandboxes immer genau einem Benutzer zugeordnet und zusätzlich durch unterschiedliche Compartments isoliert.

Zur Konfiguration von Named Secure Sandboxes sind die folgenden Schritte notwendig:

  1. Initialisierung der Labeldefinition im System
  2. Wie soll die Sandbox heißen ?
  3. Welcher User darf die Sandbox nutzen ?
  4. Welche Hierarchie zu Parent und Child Sandboxes soll genutzt werden ?
  5. Welches Label soll von welcher Sandbox genutzt werden ?
  6. Sollen Privilegien für die Sandbox limitiert werden ?
  7. Sollen Resource Controls zum Einsatz kommen (z.B. Shared Memory, CPU Zeit, ...)

Um Sandboxing in Oracle Solaris nutzen zu können, muß zunächst ein Paket nachinstalliert werden. Damit erhält man u.a. die Manpage sandboxing(7), die weitere Informationen liefert und die Kommandos sandbox(1) und sandboxadm(8).

# pkg install security/sandboxing
Danach müssen die Security Label in dem System für die Benutzung mit Sandboxes initialisiert werden. Das kann man mit labelcfg(8) machen oder zur Vereinfachung sandboxadm init nutzen. In diesem Beispiel werden 3 Klassifizierungen (Level 1-3) und 3 Compartments (Dept 1-3) genutzt. Nach der erfolgten Initialisierung sieht man mit labelcfg, welche Label in welcher Hierarchie konfiguriert wurden.
# sandboxadm init -f /etc/security/tsol/label_encodings.sandboxes \
                  -c Level -i 3 -s Dept -n 3
# labelcfg -e /etc/security/tsol/label_encodings.sandboxes commit

# sandboxadm info -e
Classifications:
    Public
    Level1 - Level3
    LevelAll
Compartments:
    Dept1 - Dept3
    DeptAll

Jetzt können die Sandboxes konfiguriert werden. Zunächst werden die Parent Sandboxes definiert. demo soll das Recht haben, alle diese Sandboxes zu benutzen. Es könnte natürlich auch für jede Sandbox ein anderer Benutzer konfiguriert werden...

# sandboxadm create -s LevelAll -u demo -c LevelAll
# sandboxadm create -s Level1 -u demo -c Level1
# sandboxadm create -s Level2 -u demo -c Level2
# sandboxadm create -s Level3 -u demo -c Level3
# sandboxadm list -l
LevelAll
    username(uid):      demo(100)
    label:              LevelAll DeptAll
Level1
    username(uid):      demo(100)
    label:              Level1 DeptAll
Level2
    username(uid):      demo(100)
    label:              Level2 DeptAll
Level3
    username(uid):      demo(100)
    label:              Level3 DeptAll

Nun werden noch zwei Child Sandboxes erzeugt, eine im Level1 und eine im Level2. Dafür werden zunächst zwei Benutzer benötigt. Die Benutzer erzeugen wir hier im Beispiel lediglich als Rollen, das sie nur im Zusammenhang mit den Sandboxes benutzt werden sollen.

# roleadd -m sbL1D1
# roleadd -m sbL2D1
# sandboxadm create -s Level1Dept1 -u sbL1D1 -p Level1
# sandboxadm create -s Level2Dept1 -u sbL2D1 -p Level2
# sandboxadm list -l
LevelAll
    username(uid):	demo(100)
    label:		LevelAll DeptAll
Level1
    username(uid):	demo(100)
    label:		Level1 DeptAll
    Level1Dept1
	username(uid):	sbL1D1(102)
	label:		Level1 Dept1
Level2
    username(uid):	demo(100)
    label:		Level2 DeptAll
    Level2Dept1
	username(uid):	sbL2D1(103)
	label:		Level2 Dept1
Level3
    username(uid):	demo(100)
    label:		Level3 DeptAll

Jetzt ist alles beisammen und die Sandboxes können benutzt werden.

Zunächst prüfen wir die Funktionalität der Label:

  • Beim Wechsel in die Sandbox wird die User-ID (falls der Benutzer unterschiedlich ist)
  • Jede Sandbox läuft in einem eigenen Project
  • In LevelAll sehen wir nur die eigenen Prozesse und die von Level1, Level2, Level1Dept1, Level2Dept1
  • Level1, Level2 sehen nur die eigenen Prozesse und die ihrer dominierten Childs
  • Level1 kann auf die eigenen Dateien und die der dominierten Childs zugreifen
  • Die Child Sandboxes können nur auf die eigenen Dateien zugreifen
demo@s11bk:~$ sandbox -s LevelAll
LevelAll $ id -p
uid=100(demo) gid=10(staff) projid=50000(LevelAll)
LevelAll $ ps -ef
     UID   PID  PPID   C    STIME TTY         TIME CMD
    demo 19664 19662   0 13:50:41 pts/1       0:00 ps -ef
    demo 19662  4899   0 13:50:23 pts/1       0:00 /usr/bin/bash --login
LevelAll $ sandbox -s Level1
Level1 $ id -p
uid=100(demo) gid=10(staff) projid=10000(Level1)
Level1 $ ps -ef
     UID   PID  PPID   C    STIME TTY         TIME CMD
    demo 19697 19695   0 13:52:33 pts/1       0:00 ps -ef
    demo 19695 19662   0 13:52:24 pts/1       0:00 /usr/bin/bash --login

LevelAll $ ps -ef
     UID   PID  PPID   C    STIME TTY         TIME CMD
    demo 19730 19729   0 13:54:25 pts/2       0:00 ps -ef
    demo 19695 19662   0 13:52:24 pts/1       0:00 /usr/bin/bash --login
    demo 19662  4899   0 13:50:23 pts/1       0:00 /usr/bin/bash --login

Level1 $ ls /export/home/sbL1D1
local.cshrc    local.login    local.profile
Level1 $ ls /export/home/sbL2D1
/export/home/sbL2D1: Permission denied

Level1 $ sandbox -s Level1Dept1
sbL1D1@s11bk:~$ pwd
/export/home/sbL1D1
sbL1D1@s11bk:~$ id -p
uid=102(sbL1D1) gid=10(staff) projid=102(Level1Dept1)
sbL1D1@s11bk:~$ plabel
Level1 Dept1

Durch Veränderung der Projektkonfiguration für die den Sandboxes zugeordneten Projekte, könnten zusätzlich Ressourcen Limits für die Projekte vergeben werden. Details dazu finden sich unter project(5), aber das soll hier kein Thema sein.

Rights Profiles

Wem das bereits Gezeigte zur Isolation noch nicht reicht, der kann die Secure Sandboxes noch weiter "zunageln". Wenn man dem User oder der Rolle einer Sandbox ein Rights Profile zuordnet, können die Privilegien der Prozesse in einer Sandbox noch weiter begrenzt werden. Das folgende Beispiel erlaubt keinen Zugriff auf das Netzwerk und ermöglicht lediglich die Ausführung von Programmen unter /usr/bin.

# cat sb.profcfg 
set desc="Sandboxed";
add cmd=*;
set privs=basic,!net_access,!proc_exec,!proc_info;
add privs={proc_exec}:/usr/bin/*;
end

# profiles -p sandbox -f sb.profcfg 
# rolemod -P +sandbox sbL1D1

demo@s11bk:~$ sandbox -s Level1Dept1
sbL1D1@s11bk:~$ zfs list
bash: /usr/sbin/zfs: Not owner
sbL1D1@s11bk:~$ ssh srv
socket: Permission denied
ssh: connect to host srv port 22: Permission denied

sbL1D1@s11bk:~$  ppriv self
20322:	ppriv self
flags = PRIV_XPOLICY|PRIV_PFEXEC|PRIV_PROC_SENSITIVE
	Extended policies:
		{proc_exec}:/usr/bin/*
	E: basic,!net_access,!proc_exec,!proc_info
	I: basic,!net_access,!proc_exec,!proc_info
	P: basic,!net_access,!proc_exec,!proc_info
	L: all

Soweit einige einführende Beispiele zu den Named Secure Sandboxes in Oracle Solaris 11.4. Die kleinen Beispiele zeigen, wie die verschiedenen Security Features von Oracle Solaris ineinander greifen und die Benutzung der Secure Sandboxes kann sehr schnell komplex werden. Hier gilt es, den Überblick zu behalten. Secure Sandboxes ermöglichen verschiedene Einsatzfälle, in denen sehr sichere Laufzeitumgebungen benötigt werden, aber eine leichtgewichtigere Virtualisierung als Solaris Zones zum Einsatz kommen sollen.

Join the discussion

Comments ( 2 )
  • Jörg Fasolack Tuesday, March 20, 2018
    Hallo,
    müßten die Beschreibungen zu ADMIN_LOW und ADMIN_HIGH nicht umgekehrt sein:
    "ADMIN_LOW:Das Label wird [..] dominiert" und
    "ADMIN_HIGH: Das Label dominiert [...]"?

    Ansonsten eine gute Einführung in ein tatsächlich kompliziertes Thema.

    Grüße,
    Jörg Fasolack
  • Detlef Drewanz Tuesday, March 20, 2018
    Vielen Dank für den Hinweis. Stimmt, da habe ich die Beschreibung leider verdreht. Ich habe das gerade korrigiert.

    Viele Grüße
    Detlef Drewanz
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.