Software::Kernel
Die Schutzmechanismen des Android-Kernels
Jeff Vander Stoep vom Android-Security-Team hat beschrieben, welche Schutzmechanismen die verschiedenen Versionen des Android-Kernels nutzen. Der Schwerpunkt liegt dabei auf den Neuerungen von Android 7 »Nougat«. Fast alle davon sind inzwischen auch im offiziellen Linux-Kernel implementiert.
android.com
Die
Schutzmechanismen des Android-Kernels lassen sich in zwei Klassen einteilen: Speicherschutz und Reduzierung der Angriffsfläche. Zur ersten Klasse gehört als erstes die Markierung von Speicher, der Daten enthält, als nicht ausführbar. Dieser wird weiter unterteilt in Daten, die nur lesbar, und Daten, die auch änderbar sind. Zuständig ist dafür die Speicherverwaltungseinheit der CPU. Mittlerweile unterstützt auch ARM64 die entsprechenden Flags, so dass nun ein Patch, der von
Grsecurity abstammt, integriert werden konnte. Die Funktionalität ist optional und wird mit der Option
CONFIG_DEBUG_RODATA aktiviert. Sie ist im offiziellen Linux-Kernel enthalten und wurde auf die Android-Kernel ab Version 3.18 portiert.
Normalerweise kann der Kernel auf den gesamten Speicher aller Anwendungen zugreifen, was aber überflüssig ist und Angriffsmöglichkeiten schafft. Daher wurde mit der Option CONFIG_CPU_SW_DOMAIN_PAN ein Schutz geschaffen, der ebenfalls seine Wurzeln in Grsecurity hat. Der Code wurde vom Russell King für ARMv7 im offiziellen Kernel implementiert und ist im Android-Kernel ab 4.1 verfügbar. Eine weitere Maßnahme ist der Stack-Schutz, der Überläufe verhindern soll. Dies war bereits in früheren Android-Kerneln verfügbar, wurde aber nochmals erweitert. Es handelt sich hierbei um eine Option des Compilers, die ab GCC 4.9 verfügbar ist.
Als Maßnahme zur Reduktion der Angriffsfläche wurde unter anderem der Zugriff auf das perf-Subsystem des Kernels für normale Anwender entfernt, da diese keinen Bedarf dafür haben. Diese Änderung beginnt mit Android 7.0 »Nougat«. Entwickler können die Funktionalität mit adb wieder einschalten. Auch hier stammt der Kernel-Teil der Änderungen wieder überwiegend von Grsecurity.
Das Sicherheitsmodell von Android macht starken Gebrauch von SELinux. Bisher war es aber nicht möglich, den Systemaufruf ioctl zu blockieren, da bestimmte Aufrufe von den Apps benötigt werden. Daher wurde die Granularität erhöht, und es ist jetzt möglich, ioctl zu blockieren, aber einzelne Ausnahmen zuzulassen. In Android Nougat werden daher nur noch eine Handvoll von ioctl-Aufrufen, die Sockets betreffen, zugelassen. In einigen Fällen sind auch noch Aufrufe, die die Grafikeinheit betreffen, erlaubt.
Schließlich gibt es auch noch den Seccomp-Mechanismus, der Anwendungen in Sandboxen einsperrt, in denen sie nur bestimmte Systemaufrufe mit eingeschränkten Argumenten ausführen dürfen. Erstmals genutzt in Android 5, wird Android Nougat Seccomp grundsätzlich nutzen. Betroffen sind davon mindestens die Prozesse mediaextractor und mediacodec.
Weitergehende Maßnahmen sind noch in Arbeit. So werden im Kernel Self Protection Project weitere Sicherheitsmaßnahmen für den offiziellen Kernel entwickelt. Der Schutz mit Hilfe von Seccomp und SELinux wird stetig erweitert. Mit Minijail wird ein Mechanismus entwickelt, um Seccomp und Namensräume bequem anwenden zu können. Andere Projekte beschäftigen sich mit Fuzz-Testern und deren Verbesserung. So wird der Kernel, nicht nur der von Android, sondern insbesondere auch der offizielle, ständig verbessert, um nicht immer nur neuen Sicherheitslücken hinterher zu laufen, sondern ganze Klassen von Lücken von vornherein zu verhindern.
){kind=logo}
