© rawpixel, 123RF

Der Lockdown-Modus macht den Linux-Kernel sicherer und bricht mit einer alten Tradition: Ist er aktiviert, darf auch Root auf einem System nicht mehr alles. Was steckt dahinter, und wozu soll das gut sein?

Zugegeben: Das Wort Lockdown ist gegenwärtig nicht sonderlich positiv konnotiert, am liebsten würde man sich mit dem Thema nicht mehr befassen. Dabei gerät in Vergessenheit, dass das Wort vor Covid-19 im normalen Alltagsenglisch auch in positiven Zusammenhängen in Gebrauch war. Vor einigen Monaten etwa akzeptierte Linux-Chef Torvalds eine Reihe von Patches für den Linux-Kernel, die dort den sogenannten Lockdown-Modus einführten. Dieser Modus macht etwas nach dem Empfinden altgedienter Linux-Veteranen ziemlich Ungeheuerliches: Er legt fest, dass der Systemadministrator (root) ebenso wie jeder x-beliebige Benutzer auch bestimmte Dinge nicht mehr tun darf.

Sakrileg

Wer, wie der Autor dieses Artikels, in der Linux-Welt der frühen 2000er-Jahre sozialisiert wurde, bekommt bei dieser Vorstellung naturgemäß beschleunigten Puls. Zur damaligen Zeit war selbst Sudo kaum erwähnenswert verbreitet. Zwar wiesen sämtliche Linux-Distributionen darauf hin, dass die permanente Arbeit als Root keinesfalls der empfohlene Weg sei; KDE blendete sogar entsprechende Warnmeldungen ein.

Immerhin bot Linux im Gegensatz zu anderen Systemen seinerzeit bereits echte Multi-User-Fähigkeiten. Doch wer auf Servern zu administrativen Zwecken eingeloggt war, wurde in aller Regel per »su -« zu Root. Damit einher ging freilich die implizite Überzeugung, dass der Benutzer mit der UID 0 der unangefochtene Herrscher über ein Linux-System ist, der sich am Ende über jede Form einer Einschränkung hinwegzusetzen vermag.

Dass der Lockdown-Modus mit diesem ehernen Gesetz nun Schluss machen möchte, mutet für manchen altgedienten Systemadministrator insofern äußerst wagemutig an. Höchste Zeit, sich die Sache einmal genauer anzusehen: Worum geht es eigentlich, wie entstand die Implementierung, und wo wird sie in Zukunft besonders hilfreich sein? Mit eben diesen Fragen beschäftigt sich dieser Artikel.

Verdammt lang her

Als Linus Torvalds die Lockdown-Patches Ende 2019 endlich in den offiziellen Kernel übernahm, berichteten viele Beobachter von einem neuen, revolutionären Feature. Doch weit gefehlt: Der Lockdown-Modus ist alles andere als eine neue Erfindung. Tatsächlich zogen sich die Arbeiten an der Implementierung der Funktion über fast sieben Jahre hin. Und wie es in der Open-Source-Welt üblich und gut ist, stritten sich die Entwickler des Linux-Kernels immer wieder – zum Teil heftig – über den richtigen Weg.

Dass es indes schon 2012 Entwickler gab, die die Notwendigkeit einer tatsächlichen Lockdown-Implementierung für den Linux-Kernel sahen, lässt erahnen, mit welchen Sicherheitsproblemen Linux schon damals konfrontiert war. Und seither wurde es um das Thema Sicherheit in der IT kaum ruhiger, ganz im Gegenteil: Security ist heute ein derart zentraler Aspekt, dass Unternehmen ganze Teams beschäftigen, die sich um nichts anderes kümmern. Wie jedoch unterstützt der Lockdown-Mode Admins und Architects dabei, die Sicherheit zu verbessern? Und auf welcher Ebene setzen die Patches eigentlich an? Ein Blick unter die Haube schafft Klarheit.

Linux Security Modules

Bereits vor einigen Jahren debattierten die Kernel-Entwickler heftig die Frage, wie sich verschiedene Sicherheitsfunktionen im Linux-Kernel sinnvoll implementieren lassen. Die Herausforderung dabei: Je nach Einsatzszenario beim Anwender kann es nötig sein, unterschiedliche Sicherheitstechniken zu unterstützen.

Mandatory Access Control ist ein Beispiel: Red Hat setzt bekanntlich auf das selbst entwickelte SELinux, während Canonical und Suse eher AppArmor verwenden. Beide Implementierungen lösen ganz ähnliche Probleme, aber auf völlig unterschiedliche Art und Weise. Die Linux-Entwickler, allen voran Linus Torvalds, wollten wie in solchen Fällen üblich sicherstellen, dass sich innerhalb der Kernel-Entwickler kein (unbemerkter) Bias im Hinblick auf ein bestimmtes Feature ergibt – dass die Entwickler also nicht eine bestimmte Technologie bevorzugen.

Diese Haltung von Linus Torvalds hat gute Tradition. Sie war seinerzeit auch der Grund dafür, warum Xen die Aufnahme in den Linux-Kernel lange verwehrt blieb. Denn Torvalds machte sich Sorgen, dass dadurch das zu dieser Zeit auch noch nicht in Linux integrierte KVM einen schwierigen Stand haben würde. Um den Streit zwischen den Hypervisoren zu schlichten, nutzten die Entwickler damals einen Trick: Sie implementierten ein Framework im Kernel, über das KVM und Xen dieselben Kernel-Funktionen nutzen konnten.

Auf eben diesen Trick griff man letztlich auch zurück, um Linux um Sicherheitsfunktionen zu erweitern. Hier heißt das Framework nicht wie bei der Virtualisierung PVops, sondern Linux Security Modules (LSM). AppArmor und SELinux nutzen beide LSM. Und auf genau diese Schiene zwang Linus Torvalds auch die Lockdown-Module für Linux. Als deren erste Versionen 2012 auf der LKML debattiert wurden, der offiziellen Mailing-Liste der Kernel-Entwickler, lehnte Torvalds die Patches schon deshalb ab, weil sie das seinerzeit schon verfügbare LSM nicht nutzten. Spätere Versionen der Patches waren entsprechend umgebaut (Abbildung 1).

Abbildung 1: Selbst Mitte 2018 debattierten die Entwickler noch heftig über die Frage, wie der Lockdown sinnvoll zu implementieren sei.

Wohlgemerkt: Die sehr generische Schnittstelle LSM erlaubt es anderem Code, sich an bestimmten Stellen in den Kernel einzuklinken und dort sicherheitsbezogene Funktionen zu implementieren. Deshalb können auch mehrere LSM-Module parallel aktiv sein. Der Lockdown-Modus schließt also nicht aus, dass AppArmor und SELinux zum Einsatz kommen.

Die Nutzung der LSM-Schnittstelle birgt einen weiteren großen Vorteil in sich, denn LSM hat ab Werk eine Policy-Schnittstelle zum Userland. Das bedeutet im Klartext, dass der Administrator zwar im Kernel bestimmte Security-Funktionen wie den Lockdown-Modus grundsätzlich aktivieren oder deaktivieren kann. Konfigurieren lässt sich das Kunstwerk anschließend jedoch aus dem Userland, und das sogar deutlich feiner abgestuft, als es der Fall wäre, würde es sich ausschließlich um Kernel-Funktionen handeln.

Wo ist das Problem?

Welches Problem will der Lockdown-Mechanismus nun lösen? Um das zu verstehen, versetzt man sich idealerweise in den Alltag eines ganz normalen Linux-Systems. Bis heute gilt: Jeder, der Root-Rechte hat, ist König des Systems und darf darauf tun und lassen, was er möchte. Das bedeutet insbesondere auch: Er darf den Kern des Betriebssystems beliebig verändern und Module mit neuer Funktionalität nachladen. Das ist aus Sicht des Admins hochgefährlich: Wenn er schon nicht verhindern kann, dass ein Gauner in das System einbricht, so möchte er das doch wenigstens früh genug merken. Das aber ist schwierig, wenn ein Angreifer zum Beispiel zentrale Kernel-Features per Modul durch eigene Versionen ersetzt, die die Spuren des Ganoven gezielt verwischen.

Moderne Computer versuchen deshalb, sich schon in ihrer Firmware gegen diese Art von Angriff zu verteidigen. In UEFI existiert dafür ein eigener Mechanismus namens Secure Boot, der vorrangig den Boot-Modus des Systems betrifft: Ein System mit aktivem Secure Boot führt einen OS-Bootloader nur aus, wenn er von einer vertrauten Stelle digital signiert wurde. Dasselbe gilt für den Kernel, den dieser Bootloader dann startet: Bei aktiviertem Secure Boot benötigt auch er eine entsprechende digitale Signatur. So soll eine Chain of Trust entstehen, dank der kein Schadcode im Kernel landet.

Das Problem: Ist der Bootloader als Hürde im System einmal überwunden, gab es in Linux bislang nichts, was das Laden von beliebigen Modulen hätte unterbinden können. Selbst wenn der ursprünglich geladene Kernel also digital signiert war, weichen nachladbare Module diese Sicherheit empfindlich auf. Die Idee der Chain of Trust ist damit beim Teufel.

Genau hier kommt der neue Lockdown-Modus ins Spiel: Mit seiner Hilfe nagelt der Admin den Kernel künftig so zu, dass auch der Systembenutzer mit der UID 0 bestimmte Kernel-Strukturen nicht ändern und – im Wachhund-Modus – noch nicht einmal sehen darf. Selbst wenn ein Angreifer also an die Rechte von Root gelangt, fiele es ihm aus den beschriebenen Gründen deutlich schwerer, seine Anwesenheit zu verstecken.

Erweiterte LSM-Features

Um den Lockdown-Modus implementieren zu können, mussten die Kernel-Entwickler den LSM-Stack sogar noch aufbohren. In seiner vorherigen Fassung war er nur darauf ausgelegt, sich um Probleme zu kümmern, sobald der Userland-Teil aktiv war, also die Umgebung, die den Kernel mit Richtlinien versorgt. Für den Lockdown im Kernel genügt das aber nicht: Ein Angreifer könnte etwa ein System so modifizieren, dass es unmittelbar nach dem Start schon Schadcode lädt. Der würde dann zwar erst beim nächsten Neustart des Systems aktiv, doch bliebe der Angreifer grundsätzlich unbemerkt.

Ein Teil des Lockdown-Patches war deshalb ein neues LSM-Modul für Early-Stage-Security, das unmittelbar nach dem Start des Kernels geladen wird. Dem Modul stehen zu diesem Zeitpunkt zwar praktisch noch keine Features des Kernels zur Verfügung, nicht einmal Speicher lässt sich mittels »malloc()« anfragen. Die durchgehende Security-Strategie jedoch steht: Ist das Early-Stage-Modul geladen, greifen alle zu diesem Zeitpunkt nötigen Vorsichtsmaßnahmen nach Vorgabe des Admins.

Den Lockdown-Modus nutzen

Um den Lockdown-Modus zu verwenden, benutzt der Admin die Parameter »lsm« und »lockdown« in der Kommandozeile des Linux-Kernels. Der Parameter »lsm« aktiviert das LSM-Subsystem und sollte für Lockdown die Argumente »lsm=lockdown,yama« erhalten. Falls LSM bereits für andere Module aktiviert wird, genügt es, »lockdown« und »yama« durch ein Komma getrennt an die bestehenden Parameter anzuhängen. Der Parameter »lockdown« kann die beiden Argumente »integrity« und »confidentiality« haben. Auf die Bedeutungen der beiden Modi geht der Artikel später noch im Detail ein.

Grundsätzlich lässt sich der Lockdown-Modus auch zur Laufzeit noch aktivieren. Das erledigt ein »echo confidentiality« oder »echo integrity« mit Umleitung zur Datei »/sys/kernel/security/lockdown«. Zur Laufzeit deaktivieren lässt der Lockdown-Modus sich freilich in keinem der zwei Szenarien. Obendrein ist das Aktivieren zur Laufzeit auch nicht ganz so sicher wie das Aktivieren per Kommandozeile, weil der volle Schutz dann eben nicht ab der ersten Sekunde gilt (Abbildung 2).

Abbildung 2: Zwar lässt sich der Lockdown-Modus auch im laufenden System aktivieren, das bietet aber nur unvollständige Sicherheit.

Integer und vertraulich

Mit der Lockdown-Implementierung offerieren die Entwickler zwei Modi, zwischen denen sich der Admin entscheiden muss. Der Integrity-Modus achtet im Wesentlichen darauf, dass Root den gerade laufenden Kernel nicht verändern kann. Er implementiert damit das, was die Entwickler mit dem gesamten Lockdown-Patch ursprünglich erreichen wollten: dass sich die Vertrauenskette zwischen dem laufenden und dem ursprünglich gestarteten Kernel herstellen lässt.

Mittlerweile hat sich der Lockdown-Modus allerdings auch weiterentwickelt. In den Fokus der Entwickler rückte dabei neben dem Schutz des laufenden Systems auch der Schutz eventuell gerade vorhandener Inhalte im Arbeitsspeicher. Auf den darf Root ebenfalls zugreifen und ihn nach Belieben auslesen. Genau das verhindert der Confidentiality-Modus: Ist er aktiv, gelingt das Auslesen nicht mehr. Das reduziert die Gefahr deutlich, dass Angreifern Passwörter oder andere vertrauliche Daten in die Hände fallen.

Wirft man einen Blick in den Linux-Quelltext (Abbildung 3), ergeben sich die konkreten Funktionen, die die beiden Lockdown-Modi im Hintergrund bei ihrer Aktivierung auslösen. Läuft der Kernel im Integrity-Modus, ist das Laden unsignierter Module verboten. Man kann das System auch nicht mehr mittels »kexec« dazu bringen, unmittelbar in einen neuen Kernel zu booten.

Abbildung 3: In der Datei »security.c« des Linux-Kernels findet sich eine Übersicht aller Funktionen, die beim aktivierten Lockdown-Kernel greifen.

Etliche Module im Linux-Kernel bieten Funktionen, die explizit als “unsafe” markiert sind. Im Integrity-Modus verhindert der Kernel, dass Root Parameter nutzt, die solche Module laden. Versucht er das, bekommt er vom Kernel direkt ein Permission Denied zurück. Als unsicher erkannte MMIO-Operationen unterbindet der Kernel zudem ebenso wie bestimmte Arten, »perf« zu verwenden. Ebenfalls wichtig: Über die ACPI-Tabellen eines Systems ist es grundsätzlich möglich, den laufenden Kernel zu modifizieren und ihn so zu kompromittieren. Daher deaktiviert der Integrity-Modus auch diese Operationen pauschal. Für mobile Systeme zudem interessant: Der Lockdown-Modus deaktiviert das Hibernation-Feature.

Noch strenger

Betreibt der Admin sein System im Confidentiality-Modus, kommt noch eine Schippe mit Maßnahmen obendrauf. Zugriffe auf »/dev/mem«, »/dev/kmem« und »/dev/port« unterbindet der Kernel dann ebenso konsequent wie den direkten Zugriff auf PCI-Geräte. Traffic auf seriellen Ports darf Root auf solchen Systemen ebenfalls nicht mehr mitlesen. Der Zugriff auf »debugfs« zu Debugging-Zwecken ist ebenso deaktiviert wie jener auf »/proc/kcore«. Auch mittels Berkeley Packet Filter (BPF) lässt sich das Kernel-RAM dann nicht mehr direkt auslesen.

Kompatibilitätsprobleme

In Summe deaktiviert der Lockdown-Modus im Kernel diverse Features, die manche Userland-Software ausgiebig nutzt. Man kennt das Problem als Admin ja grundsätzlich: Funktionen, die eigentlich nur für Debugging konzipiert sind, bleiben plötzlich dauerhaft angeschaltet oder werden auch außerhalb des Debugging-Kontexts genutzt. Das geschieht meist, um ein dringendes Problem zu lösen, doch kümmert sich in den meisten Fällen anschließend niemand mehr um diese technische Schuld.

Viele der Funktionen, die der Lockdown-Modus deaktiviert, sind ausdrücklich nur für Debugging vorgesehen, existieren aber seit Jahren und Jahrzehnten. Dass diverse Userland-Software sie benutzt, darf als sicher gelten. Das stellt den Administrator vor der Einführung des Lockdown-Patches jedoch vor ein Problem: Er muss damit rechnen, dass zumindest einige Programme anschließend nicht mehr richtig funktionieren.

Die Kernel-Entwickler betrachten Lockdown deshalb als optionales Feature, das ab Werk nicht standardmäßig aktiviert ist. Will ein Admin die Funktion nutzen, sollte er einige Zeit einplanen und auf Testsystemen herausfinden, ob seine Software anschließend wie gehabt funktioniert. Das gilt besonders für den Confidentiality-Modus. Als Kompromiss können Admins hier womöglich zumindest den Integrity-Modus benutzen, der es vermeidet, dass Angreifer systematisch Security-Löcher reißen.

Nicht auszuschließen ist allerdings auch, dass die Kernel-Entwickler – oder zumindest die Linux-Distributoren – in Zukunft restriktiver werden, was Lockdown angeht.

Zusätzliche Absicherungen

Wer den Lockdown-Modus nutzen will, sollte beim Betrieb seiner Umgebung ein paar zusätzliche Faktoren überwachen. Die schönsten Features im Kernel helfen schließlich nicht, wenn ein Angreifer sie unbemerkt deaktivieren kann und sich so letztlich doch wieder vollen Zugriff erschleicht.

Manche Dinge lassen sich auch per Lockdown im Kernel nicht verhindern – etwa, dass der Admin bestimmte Dateien im System verändert. Konfiguriert ein Bösewicht allerdings kurzerhand Grub um, damit der Lockdown-Modus gar nicht erst aktiviert wird, fällt dessen Schutz weg. Obendrein wäre es auch nicht sehr praktikabel, die Bootloader-Konfiguration zu schützen – sie muss ja auch im Rahmen regulärer System-Updates verändert werden. Worauf sollte der Admin also achten?

Regelmäßig prüfen

Ob der Lockdown-Modus aktiv ist, lässt sich am einfachsten über die Kommandozeile feststellen. Das funktioniert über »/proc/cmdline«. Beim Monitoring sollte der Admin also überprüfen, ob in dieser Datei der Parameter »lockdown« definiert ist und ob er den Wert »confidentiality« oder »integrity« hat. Das LSM-Modul »lockdown« sollte ebenfalls in der Kommandozeile vermerkt sein, weil der »lockdown«-Parameter andernfalls wirkungslos bleibt.

Auch ohne Lockdown-Mode im Kernel sollten beim Admin sämtliche Alarmglocken läuten, wenn ein System unerwartet neu startet. Meistens wird es dabei um ein Problem durch defekte Hardware oder kaputte Treiber gehen. Der Admin möchte hierüber schnell die nötige Klarheit haben. Es könnte sich allerdings auch um einen Angreifer handeln, der das System nach einer Änderung der Konfiguration des Bootloaders neu startet, um einen Non-Lockdown-Kernel zu bekommen.

Das Problem: Hat er das erst einmal geschafft, ist es durchaus möglich, dass »/proc/cmdline« behauptet, Lockdown sei aktiv, ohne dass das der Fall wäre. Es empfiehlt sich deshalb, ein paar zusätzliche Dateien des Systems zu überwachen. Dazu zählt beispielsweise »/boot/grub/grub.cfg« – auch hier sollte der Lockdown-Modus entsprechend zu finden sein.

Nicht zu sicher fühlen

Klar sein muss aber auch, dass es absolute Sicherheit nicht gibt. Staatlich finanzierte Hacker scheuen in aller Regel keine Mühen und sind entsprechend in der Lage, hochkomplexe Angriffe zu fahren. Faktisch könnte ein Angreifer also beispielsweise einfach den Bootloader überschreiben und eine eigene Konfigurationsdatei nutzen, sodass sich an der im System hinterlegten »grub.cfg« nichts ändert.

Dem käme der Admin nur auf die Schliche, indem er prüft, ob der gerade laufende Kernel auch der ist, den der Hersteller ausgeliefert hat. Wer sein System gegen entsprechende Angriffe absichern möchte, hat also viel zu tun. Ein Freibrief dafür, die Füße hochzulegen und sich um das Thema Sicherheit nicht länger zu kümmern, ist der Lockdown-Modus im Linux-Kernel sicher nicht.

Hilft nicht immer

Da stellt sich die Frage, ob es auch Dinge gibt, vor denen der Lockdown-Modus des Linux-Kernels Systeme nicht schützt. Die Antwort auf diese Frage ist ein klares Ja.

Zum Beispiel richtet Lockdown gegen sämtliche Hardware-bezogenen Fehler nichts aus. Prominente Beispiele sind Spectre und Meltdown: Dabei handelt es sich ja um Bugs, die den Prozessor der Systeme betreffen, also deren zentrale Recheneinheit. Zwar sind Spectre und Meltdown mittlerweile durch andere Kernel-Workarounds unschädlich gemacht (zum Teil unter erheblichen Einbußen bei der verfügbaren Performance, weil die defekten Code-Pfade der CPUs einfach ausgeschaltet werden). Der Lockdown-Modus hätte gegen diese Fehler aber auch nicht zu helfen vermocht.

Ähnlich verhält es sich, wenn der Linux-Kernel selbst unbemerkte Bugs hat, die den Lockdown-Modus umgehen. Das war zum Beispiel im Juni 2020 der Fall, als ein Bug im ACPI-Code das Nachladen von Kernel-Code vorbei am UEFI-Secure-Boot-Interface und auch vorbei am Lockdown-Modul ermöglichte.

Fazit

Der Lockdown-Modus ist beileibe nicht bloß ein abstraktes Sicherheits-Feature, das in Spezialszenarien ein Quäntchen Sicherheit bringt. Nach über sieben Jahren ist es Hauptentwickler Matthew Garrett stattdessen gelungen, eine handfeste Funktion in den Linux-Kernel zu integrieren, die direkt und unmittelbar die Sicherheit des Systems erheblich erhöht [1]. Dass es vorher keine Möglichkeit gab, auf Linux-Systemen das Nachladen von beliebigem Kernel-Code durch Root zu unterbinden, führte letztlich die Sicherheitsbestrebungen von Komponenten wie UEFI ad absurdum.

Obendrein führt der Lockdown-Modus nochmals allen Administratoren ganz klar vor Augen, dass der Feind eben nicht zwingend von außen kommt. Man möchte kaum glauben, dass es im Jahr 2020 noch immer Sicherheitskonzepte gibt, die vom sicheren internen und vom unsicheren externen Netz sprechen – und doch sind diese Setups eher die Regel als die Ausnahme. Hat ein Angreifer sich unberechtigten Zugang zu einem System verschafft und ist dort erst einmal Root, greifen fast alle Sicherheitsvorkehrungen der meisten Setups fatal ins Leere. Dem schieben die Kernel-Entwickler in Form des Lockdowns gekonnt einen Riegel vor, der sich höchstens durch eine Fehlfunktion im Kernel-Code entfernen ließe.

Zugute halten darf man Matthew Garrett obendrein, dass es nicht sehr schwer ist, den Lockdown-Modus zu nutzen. Ein einzelner Parameter für die Kernel-Kommandozeile genügt. Admins tun gut daran, sich das Feature zeitnah anzusehen und gegebenenfalls für die eigenen Systeme zu verwenden. Aber Vorsicht: Gut möglich, dass so manche Userland-Software auf die Nase fällt, weil sie unzulässigerweise Kernel-Features nutzt, die eigentlich bloß für Debugging konzipiert sind. Vor einem flächendeckenden Umstieg auf Lockdown-Kernel sollten Administratoren insofern testen und tüfteln (Abbildung 4).

Abbildung 4: Leider nein: Ist der Confidentiality-Modus aktiv, fällt das Programm auf die Nase, das hier per »bpf« das Kernel-RAM auslesen will.

Übrigens: Seinen Einzug in den Kernel hielt der Lockdown-Modus ganz offiziell in Linux 5.4. Das ist eine Version, die zahlreichen Desktop-Systemen mittlerweile beiliegt. Bei den Enterprise-Distributionen sieht die Lage hingegen eher mau aus. Ubuntu 20.04 LTS liefert als einzige Distro einen hinreichend aktuellen Kernel, um den offiziellen Lockdown-Modus zu verwenden. Auf RHEL-Systemen steht die Funktion aktuell nicht zur Verfügung; es ist allerdings anzunehmen, dass der Hersteller das Problem in einem künftigen RHEL-8-Release durch einen Patch beseitigen wird. Ähnlich dürfte Suse das Thema handhaben, zumal man in der Vergangenheit an der Lockdown-Entwicklung als Teil von Garretts Team selbst beteiligt war. Admins brauchen also eventuell noch ein bisschen Geduld, bis sie das Feature nutzen können. (jcb)