In diesem Artikel möchte ich mich mit Security Enhanced Linux (SELinux) beschäftigen. Zu Beginn werde ich einige generelle Aspekte von SELinux erläutern und zum Schluss auf die Verwendung in Android OS eingehen. Das Thema ist sehr vielseitig und zugegeben, SELinux ist eine der komplizierteren Technologien, was wohl dazu führte, dass es gut und gerne ausgeschaltet und ignoriert wird.

Verschiedene Linux Distributionen haben ausführliche Tutorials und How-To Artikel zum Thema SELinux. Erwähnenswert ist die Sammlung von Artikeln für Gentoo Linux und der Guide für RHEL6, beide dienten als Basis für diesen Artikel.

Geschichte

Neben dem Punkt, dass es nicht gerade das verständlichste Konzept ist, ist die Herkunft von SELinux wohl ein weiterer Punkt, der Kritiker nicht dazu ermutigt, sich damit auseinanderzusetzen. Bedenken wir die Ereignisse vom Mai 2013 und den NSA-Enthüllungen, so wird es einige Leute geben, die keine Freude daran haben, dass ihr Kernel mit Modulen erweitert wurden, die aus einem Research Projekt der National Security Agency (NSA) hervor gingen. Die NSA und die Secure Computing Corporation (SCC) untersuchten zusammen der Einsatz von Type Enforcement basierten Zugriffskontrollen.

In einem weiteren Schritt wurde in Zusammenarbeit mit der University of Utah die Systemarchitektur Flask entwickelt. Flask wurde auf Linux, Solaris und einzelne BSD Projekte portiert und die Verbreitung des Konzepts wurde vorangetrieben.

Die NSA-Herkunft wurde und wird auch heute noch von Kritikern ins Feld geführt. Bis dato ist aber keine Bestätigung einer Backdoor im SELinux Code bekannt. Der Source Code ist öffentlich verfügbar, seit 2003 Teil des Linux Kernel und bestimmt von einigen Leuten bereits analysiert worden. Denn bereits vor PRISM gab es diese Kritik und jedem, der eine Zeile Code mit einer Bestätigung finden könnte, würde wohl oder übel Schlagzeilen machen.

Was ist SELinux

SELinux ist die Implementation eines Mandatory Access Control (MAC) Mechanismus auf Kernelebene. Sowohl Linux als auch Unix wurden in einer Zeit entwickelt, in der Sicherheit nicht allzu hoch auf der Prioritätenliste stand. Sicherheitskonzepte entstanden und weit verbreitet ist die Discretionary Access Control (DAC), in der die Zugriffskontrolle über die Identität eines Subjekts (unter anderem kann das Benutzer oder Prozess sein) auf ein Objekt (zum Beispiel eine Datei) erlaubt wird. In Linux kennen wir die Umsetzung von DAC als Berechtigungsmaske (bsp: rwxrw-r--). Typischerweise kann bei einem DAC-Konzept einem Objekt auch immer ein Besitzer zugeordnet werden.

Bei einem MAC Mechanismus werden mehr Faktoren als nur die Identität zur Zugriffsentscheidung herbeigezogen. Im Gegensatz zu DAC-Regeln sind diese nicht durch den Besitzer eines Objektes veränderbar, was die Flexibilität einschränkt, aber gleichzeitig vor ungewollten Freigaben schützt. Der Einsatz von SELinux als MAC bedeutet jedoch nicht, dass auf das DAC verzichtet wird. Im Gegenteil, das DAC bildet die erste Zugriffskontrolle: Wird bereits hier der Zugriff verwehrt, kommt SELinux nie zur Anwendung. Wird jedoch einem Subjekt der Zugriff auf das gewünschte Objekt ermöglicht, werden die SELinux Policies konsultiert.

SELinux Betriebsmodus

SELinux kennt drei unterschiedliche Betriebsmodi. Je nach Distribution wird der Kernel unterschiedlich konfiguriert. So wird bei Red Hat (und auch den verwandten Systemen Fedora und CentOS) nach der Installation der Enforcing Modus aktiviert.

• Enforcing: Die Policy muss berücksichtigt werden und Zugriffe werden durch die Regeln geblockt
• Permissive: Die Policy muss nicht berücksichtigt werden, Zugriffe werden durch die Regeln nicht geblockt, aber in ein Log geschrieben
• Disabled: Die Policy wird komplett ignoriert

Auf einem Linux-System kann mit dem Befehl sestatus oder in der Datei /etc/selinux/config der applizierte Status ausgelesen werden.

Grundsätzlich ist der Permissive Modus während dem System-Setup und für das Debugging empfohlen. Die Funktionalität des Systems wird nicht beeinträchtigt und doch werden die potentiellen Probleme in einem Log zusammengetragen. Durch konstantes Konsultieren des Logs können die Regeln verfeinert und angepasst werden. Am Ende sollten keine gewollten Zugriffe mehr geloggt, bzw. geblockt werden. Einem produktiven Einsatz mittels Enforcing Mode steht dann nichts mehr im Weg.

SELinux Context

Die Zugriffsentscheide basieren auf Policy-Regeln. Diese wiederum werden auf einen SELinux Context angewendet, die eine Datei oder Prozess hat. Ein solcher Kontext, setzt sich aus den Abschnitten SELinux_User:SELinux_Role:SELinux_Type:SELinux_Level zusammen. Hier ein Beispiel:

[root@localhost ~]# ls -Z test.sh
-rwxr--r--. root root unconfined_u:object_r:admin_home_t:s0 test.sh

User

Jeder Benutzer auf dem System ist einem SELinux_User zugeordnet. Nicht zwingend hat dabei jeder Benutzer einen eigenen, dafür gibt es den Default Eintrag. Bestehende Mappings können dem Befehl semanage login -l aufgelistet werden.

[root@localhost ~]# semanage login -l
Login Name                SELinux User              MLS/MCS Range
default                   unconfined_u              s0-s0:c0.c1023
root                      unconfined_u              s0-s0:c0.c1023
system_u                  system_u                  s0-s0:c0.c1023

Role

Die Beziehung zu einer SELinux_Role wird mittels SELinux_User hergestellt. Es handelt sich um ein n:n Mapping. Mit dem Befehl semanage user -l kann die Relation zwischen SELinux_User und Roles dargestellt werden.

[root@localhost ~]# semanage user -l


              Labeling  MLS/       MLS/
SELinux User  Prefix    MCS Level  MCS Range       SELinux Roles
git_shell_u   user      s0         s0              git_shell_r
guest_u       user      s0         s0              guest_r
root          user      s0         s0-s0:c0.c1023  staff_r sysadm_r system_r unconfined_r
staff_u       user      s0         s0-s0:c0.c1023  staff_r sysadm_r system_r unconfined_r
sysadm_u      user      s0         s0-s0:c0.c1023  sysadm_r
system_u      user      s0         s0-s0:c0.c1023  system_r unconfined_r
unconfined_u  user      s0         s0-s0:c0.c1023  system_r unconfined_r
user_u        user      s0         s0              user_r
xguest_u      user      s0         s0              xguest_r

Anhand der SELinux_Roles wird verfeinert, auf welche Domains und somit auf welche Objekttypen (SELinux Type) zugegriffen werden können. Im obigen Konsolen-Output ersichtlich ist, dass der default SELinux_User (unconfined_u) zu zwei SELinux_Roles (system_r/unconfined_r) zugriff hat. Dies ist ein wichtiges Detail und kann durchaus zu Verwirrung führen. Angenommen, ein Benutzer kann gemäss Dateiberechtigung ein Programm ausführen, doch ausgeführt wird nichts. So kann dies daran liegen, dass die SELinux_Role kein Zugriff auf den Type erlangen darf. Der Befehl seinfo ermöglicht das Auflisten der SELinux_Types zu einer entsprechenden SELinux_Role.

[root@localhost ~]# seinfo -runconfined_r -x
   unconfined_r
      Dominated Roles:
         unconfined_r
      Types:
         bootloader_t
         netutils_t
         sandbox_x_client_t
         virt_content_t
         policykit_grant_t
         httpd_user_htaccess_t
         update_modules_t
         telepathy_mission_control_home_t
         gnome_home_t
         sandbox_net_client_t
         ldconfig_t
		...

Type

SELinux gruppiert unterschiedliche Typen in so genannte Klassen. Die wichtigsten sind wohl file_type und domain. Nicht jeder SELinux Type kann für jedes Objekt gesetzt werden, wie dies Dan Walsh in seinem Blog eindrücklich erklärt. Wird ein Type auf einen Prozess gesetzt, spricht man von einer Domain. Der Prozess erhält sozusagen eine Sandbox. Wird ein Type auf eine Datei gesetzt, wird dabei die Zugriffsrechte eines SELinux_Users definiert.

Level

Das Attribut SELinux_Level (teilweise auch Range genannt) ist optional. Es besteht aus zwei Werten, Sensitivity und Category-set:

• Der Sensitivity Wert, auch Multi-Level Security (MLS) Level genannt, wird verwendet, wenn ein Mandatory Access Model nach Bell-La Padula umgesetzt werden soll.
• Der Category-set Wert, auch Multi-Category Security Range genannt, wird verwendet wenn nur ein MLS Level besteht.

Android und SELinux

Das Android OS basiert auf einem Linux Kernel. SELinux gibt es schon seit einigen Jahren und wurde auch bereits in den Kernel integriert. Einige Distributionen haben es standardmässig aktiviert, bei anderen kann man dies selbständig tun. Seit dem Release von Android 4.3 – Jelly-Bean verwendet auch das Android OS SELinux als Mandatory Access Control (MAC). Dazu wurde das Projekt SEforAndroid ins Leben gerufen, welches sich mit der Umsetzung von SELinux auf dem AndroidOS beschäftigt.

Bei der Einführung mit JellyBean wurde SELinux erst im Permissive Mode ausgeführt. Der Permissive Mode loggt Policy Verstösse, jedoch werden diese nicht verhindert. Das Ziel war es wohl erst, Erfahrungen zu sammeln, um in einem späteren Release den Enforcement Modus (loggen und blockieren) zu aktivieren.

Ein Blick in die Neuerungen von Android 4.4 – KitKat zeigt, dass dies nun geschehen ist. Zum ersten Mal wurde SELinux im Enforce Modus ausgeliefert, jedoch reduziert auf einzelne wenige Domains. Konkret handelt es sich um die Root Domain und Root-Level Prozesse (initd, installd und vold). Jede Applikation hat eine eigene Domain und die Identifikation geschieht über den Key, mit welchem die App signiert wurde. Die Domains von Applikationen werden derzeit noch im Permissive Mode gehalten. Dies ermöglicht den Entwicklern, den Fokus auf SELinux zu richten und die registrierten Verstösse in den Logs zu analysieren, während die Applikation normal funktioniert. Auswirkungen hat es jedoch, wenn eine Applikation mit einer der Domains interagiert, welche im Enforcing Mode laufen. Sollten diese einen Policy-Verstoss zur Folge haben, werden sie abstürzen.

Bereits vor der Verwendung von SELinux kannte Android ein Sandboxing, dieser Ansatz wird weiter geführt. Die Applikations-Sandbox basierte auf automatischer Vergabe von dedizierten UID für einzelne Prozesse. Es existierten daher keine zwei Prozesse, die unter dem selben Benutzer laufen.

Fazit

SELinux bietet die Möglichkeit, auf der Kernelebene Zugriffskontrollen zu implementieren. Dieser Artikel gab eine oberflächliche Darstellung einiger dieser Aspekte. Die vollständige Implementation von SELinux bedarf grösserem Aufwand. Android, das einen Linux Kernel verwendet, setzt SELinux (bzw. SEforAndroid) bereits jetzt für einzelne Bereiche im Enforcement Modus ein. Applikationsentwickler sind von Google angehalten, für neuere Versionen die SEforAndroid Funktionalität zu berücksichtigen. Es ist ein weiteres Element in der Android Architektur um ein möglichst solides Sandboxing zu ermöglichen.

Über den Autor

Oliver Kunz ist seit 2010 im Bereich der Informationssicherheit aktiv. Hauptsächlich setzt er sich mit Incident Response, Computerforensik und der Sicherheit von mobilen Geräten auseinander.

Links

• http://danwalsh.livejournal.com/54803.html
• http://developer.android.com/about/versions/jelly-bean.html
• http://developer.android.com/about/versions/kitkat.html
• http://selinuxproject.org/
• http://selinuxproject.org/page/SEAndroid
• http://www.redhat.com
• https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/
• https://source.android.com/devices/tech/security/se-linux.html
• https://wiki.gentoo.org/wiki/SELinux/Tutorials