Login
Newsletter
Werbung

Fr, 31. Mai 2019, 11:14

Software::Kernel

Sicherheitsverbesserungen im Linux-Kernel 5.1

Die am 5. Mai freigegebene neue Version 5.1 von Linux enthält neben den bereits anderweitig genannten Änderungen auch weitere Maßnahmen zur Erhöhung der Sicherheit. Kees Cook erläutert sie im Detail.

Larry Ewing

Kees Cook ist seit 2011 bei Google und arbeitet dort an der Sicherheit von Chrome OS. Außerdem arbeitet er zusammen mit anderen daran, weitere vorbeugende Sicherheitsmaßnahmen in den Linux-Kernel zu integrieren. Einige der Maßnahmen stammen aus der Chrome OS- und Android-Entwicklung von Google, andere von Grsecurity und von weiteren Personen. Für jede Linux-Version veröffentlicht Cook eine Zusammenfassung der Neuerungen in diesem Bereich.

Linux 5.1 ist am 5. Mai erschienen und brachte unter anderem das neue Sicherheitsmodul SafeSetID mit. Kees Cook erläutert das Modul in seinem neuen Beitrag und weist zugleich auf einige weitere Änderungen hin.

SafeSetID ist ein neues Linux Security Module (LSM), das es ermöglicht, die CAP_SETUID-Berechtigung von Prozessen einzuschränken. Prozesse mit diesem Recht können sich zu jedem Benutzer einschließlich Root machen. Das in ChromeOS bereits verwendete Modul schränkt ein, welche Benutzer und Gruppen mittels setuid-Programmen ihre Rechte ausweiten dürfen. Das macht es wesentlich sicherer, normalen Benutzern entsprechende Rechte zu geben.

In diesem Zusammenhang wird der Wunsch, nicht nur ein einzelnes Sicherheitsmodul, sondern mehrere laden zu können, noch einmal größer. Der Wunsch besteht bereits seit 15 Jahren oder mehr. Jetzt wurde ein weiterer Teil davon verwirklicht, so dass man als Parameter mit lsm= angeben kann, welche Module geladen werden sollen. Laut Cook war es zwar bisher bereits möglich, einige einfache Module, die keine internen Zustände speichern, zusammen zu verwenden, dies wird jetzt aber auch mit einigen komplexeren Modulen möglich.

Einen Prozess über seine Prozess-ID anzusprechen, ist nicht vollständig sicher: Der adressierte Prozess könnte sich bereits beendet haben und ein anderer Prozess mit derselben ID an seine Stelle getreten sein. Zwar müssen extrem viele Prozesse in schneller Folge erzeugt werden, um diese Situation zu erreichen, doch das ist in der Praxis auch machbar. Um diese Lücke zu schließen, wurde jetzt das Konzept von Prozess-Dateideskriptoren (pidfd) eingeführt. Einen solchen Deskriptor kann man erhalten, wenn man /proc/$pid öffnet. Man kann ihn dann als Argument für den neuen Systemaufruf pidfd_send_signal nutzen, um ein Signal zu senden. Das Signal wird nur ausgeliefert, wenn der empfangende Prozess noch derselbe ist wie beim Aufruf von open. Offensichtliche Voraussetzung dabei ist, dass open den richtigen Prozess adressierte. In Zukunft wird es wohl auch direktere Möglichkeiten geben, eine pidfd zu erhalten.

Eine vorbeugende Maßnahme im Kernel ist eine explizite Prüfung, das von Prozessen gemappte Heap-Speicherbereiche nicht auf Kernel-Heap-Speicher angewandt werden. Dies könnte passieren, wenn Treiber fehlerhaft sind. Weiterhin in Arbeit sind zum einen die Bestrebung, das implizite Durchfallen von einem Fall einer case-Anweisung in den nächsten aus dem gesamten Kernel-Code zu beseitigen, zum anderen die Konvertierung von Referenzzählern vom Typ atomic_t nach refcount_t.

Die case-Anweisung in C hat die Eigenheit, dass das Ende jedes Falles mit einer break-Anweisung abgeschlossen werden kann, aber nicht muss. Programmierer können dies in cleverer Weise nutzen, um ein paar Bytes Code zu sparen - heutzutage ist die Ersparnis fraglich, da der Compiler den Code eventuell selbst besser anordnen kann. Die meisten Fälle, in denen das break fehlt, sind allerdings schlichtweg Fehler, wo die Anweisung vergessen wurde. Die Compiler-Option -Wimplicit fall-through kann alle diese Fälle finden. Um allerdings keine falschen Warnungen zu erhalten, soll der Kernel von allen Stellen gesäubert werden, wo das break bewusst weggelassen wurde. Hierbei wurden tatsächlich eine Reihe von Fehlern gefunden. Auch bei der zweiten Änderung ist Handarbeit angesagt, da sich nicht einfach überall atomic_t durch refcount_t ersetzen lässt. Jede Stelle muss überprüft werden. Aber auch diese Arbeit hat sich laut Cook bereits gelohnt, da so etliche Fehler entdeckt wurden.

Das GCC-Plugin »structleak« wurde in der letzten Zeit verbessert und kann nun auch skalare Typen initialisieren. Damit kann sichergestellt werden, dass bei Funktionsaufrufen alle übergebenen Variablen initialisiert werden, auch wenn sie als Referenz übergeben werden. Laut Cook ist die Auswirkung auf die Geschwindigkeit des Codes vernachlässigbar und er würde diese Funktionalität, die auch in Clang vorhanden ist, gern im Kern von GCC statt in einem Plugin sehen.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung