Schutz, Isolation und virtuelle Maschinen

Ein Programm braucht genügend Freiheit, um schnell zu rechnen, ohne die Kontrolle über den gesamten Computer zu erlangen. Im Benutzermodus kann es gewöhnliche Befehle direkt ausführen. Der Kernelmodus, auch Supervisormodus genannt, gibt dem Betriebssystem Zugriff auf die Befehle, die den Rechner steuern.

Lass die Hardware Privilegien durchsetzen

Die CPU besitzt eine aktuelle Privilegstufe. Additionen, Lade- und Speicherzugriffe sowie Sprünge laufen normalerweise mit voller Geschwindigkeit, soweit die Speicherberechtigungen es erlauben. Der Kernel prüft nicht jeden Befehl per Software. Das ist eingeschränkte direkte Ausführung: direkte Ausführung, bis eine geschützte Operation oder ein Interrupt den Kernel benötigt.

Ein privilegierter Befehl löst einen Trap aus, wenn Benutzercode ihn auszuführen versucht. Auf x86-64 benötigen HLT, das Beschreiben des Seitentabellen-Basisregisters CR3 und das Einrichten einer Interrupttabelle mit LIDT Kernelprivilegien. Andernfalls könnte eine Anwendung die CPU anhalten, ihre eigenen Speichergrenzen ersetzen oder die Interruptbehandlung umleiten.

Angenommen, eine Anwendung führt HLT aus. Die CPU löst eine allgemeine Schutzverletzung aus, statt anzuhalten. Sie ruft die vom Kernel registrierte Behandlungsroutine auf. Linux sendet dem Prozess normalerweise SIGSEGV und beendet ihn, während andere Programme weiterlaufen. Die Anwendung kann nicht eine beliebige passende Adresse innerhalb des Kernels wählen und dort mit der Ausführung beginnen.

Überschreite die Grenze über einen kontrollierten Eintrittspunkt

Traps, Ausnahmen und Interrupts führen über vom Kernel registrierte Adressen in den Kernel. Die Hardware ändert die Privilegstufe und überträgt die Kontrolle an die Behandlungsroutine; der Eintrittscode des Kernels sichert den für die Rückkehr nötigen Zustand. Ein spezieller Rücksprungbefehl stellt die Ausführung im Benutzermodus am gespeicherten Befehlszähler wieder her. Auf x86-64 kann die Rückkehr SYSRET oder IRETQ nutzen.

Der Timer macht diese Kontrolle auch dann nutzbar, wenn ein Programm nie eine Leistung anfordert. Bevor der Kernel es ausführt, programmiert er einen Timer. Wenn der Interrupt eintrifft, kann der Scheduler einen anderen Prozess auswählen. Benutzercode kann weder Interrupts abschalten noch diesen Timer umprogrammieren. Daher kann eine Endlosschleife einen Kern nicht für immer belegen.

Lies Privilegdiagramme richtig

Die Nummerierung unterscheidet sich: Eine niedrigere x86-Ringnummer bedeutet mehr Privilegien, während eine höhere ARM-Ausnahmeebene mehr Privilegien bedeutet. Die Intel-Virtualisierung ergänzt außerdem VMX-Root- und Non-Root-Betrieb; diese sind unabhängig von der Ringnummer.

Trenne Identität und CPU-Modus

Root ist eine Benutzeridentität, UID 0, die Kernelsoftware erkennt. Der gewöhnliche Code einer Root-Anwendung läuft weiterhin im Benutzermodus und wechselt über Systemaufrufe in den Kernel. Ein Gerätetreiber im Kernelmodus hat erheblich mehr direkte Befugnisse: Ein Speicherfehler dort kann den Kernelzustand beschädigen, ohne eine Dateiberechtigungsprüfung zu durchlaufen.

Die Ebene, die eine Grenze durchsetzt, muss die Ebene darin kontrollieren. Der Kernel setzt Prozessgrenzen mit CPU-Modi und Speichertabellen durch. Ebenso kontrolliert ein Hypervisor Gastbetriebssysteme mithilfe der Hardwareunterstützung für Virtualisierung.

Ein Systemaufruf ist eine kontrollierte Anfrage nach einer Leistung des Kernels. Das Öffnen von Dateien, Erzeugen von Prozessen und Senden von Netzwerkdaten erfordert jeweils Entscheidungen, die eine Anwendung nicht sicher selbst treffen kann. Der Eintritt in den Kernel gibt der Behandlungsroutine Befugnisse; er erlaubt dem Aufrufer nicht, alles Angeforderte zu tun.

Verfolge die Anfrage

Ein Bibliothekswrapper der C-Bibliothek wie open() legt die Aufrufnummer und die Argumente in Registern ab. Er nutzt SYSCALL auf x86-64, SVC auf ARM64 oder ECALL auf RISC-V. Der Kernel führt dann folgende Schritte aus:

1. Er tritt über seinen registrierten Eintrittspunkt ein und sichert Benutzerregister.
2. Er wählt die Behandlungsroutine aus der Systemaufruftabelle und weist eine unbekannte Nummer zurück.
3. Er liest Identität und Anmeldeinformationen des Aufrufers aus dem aktuellen Prozess.
4. Er prüft Argumente, Zugriffsrechte und die beteiligten Objekte.
5. Er führt die Operation aus oder gibt einen Fehler zurück.
6. Er stellt den gesicherten Zustand wieder her und kehrt in den Benutzermodus zurück.

Die Identität stammt aus den Anmeldeinformationen des Prozesses, nicht aus einem vom Benutzer angegebenen Namen. Ein Aufrufer kann die Rechte eines anderen Benutzers nicht erhalten, indem er dessen Namen zu einer Anfrage hinzufügt.

Behandle Argumente als nicht vertrauenswürdig

Ein Zeiger ist lediglich eine vom Aufrufer angegebene Zahl. Der Kernel muss den gesamten angeforderten Benutzerspeicherbereich einschließlich Länge und Zugriffsrichtung prüfen. Linux nutzt geprüfte Routinen wie copy_from_user und copy_to_user, um die Grenze sicher zu überschreiten.

Bei read(fd, buf, 4096) darf ein buf, das in den Kernelspeicher zeigt, nicht zum Ziel für Dateidaten werden. Linux meldet für diesen ungültigen Benutzerpuffer EFAULT. Ein anderer Fehler hat eine andere Ursache: write() über einen mit O_RDONLY geöffneten Deskriptor schlägt mit EBADF fehl, weil für den Deskriptor nie Schreibzugriff gewährt wurde. Eine gewöhnliche abgelehnte Anfrage gibt einen Fehler zurück; sie beendet den Prozess nicht automatisch. In C gibt der Wrapper gewöhnlich −1 zurück und setzt errno.

Prüfe das tatsächlich verwendete Objekt

Eine TOCTTOU-Wettlaufsituation trennt eine Entscheidung von dem Objekt, das sie schützen sollte. Ein privilegiertes Hilfsprogramm prüft access("/tmp/report", W_OK) und öffnet dann den Pfad. Ein Angreifer ersetzt den Pfad zwischen diesen Operationen durch einen symbolischen Link auf /etc/passwd. Der Name ist unverändert, aber das geöffnete Objekt ist ein anderes.

Die Lösung besteht darin, unter der vorgesehenen Identität auf das tatsächlich geöffnete Objekt zuzugreifen. Gib vor dem Öffnen Privilegien ab und nutze Flags wie O_NOFOLLOW, wenn symbolische Links unerwünscht sind. Argumente einmal in den Kernelspeicher zu kopieren vermeidet ebenfalls, veränderlichen Benutzerdaten wiederholt zu vertrauen; die kopierte Struktur muss dennoch geprüft werden.

Bestimme, was vertrauenswürdig sein muss

Ein Referenzmonitor vermittelt Zugriffe. Er muss immer aufgerufen werden, wenn Zugriff erlangt wird, vor Manipulation geschützt und klein genug sein, um ihn sorgfältig zu untersuchen. Nachdem der Kernel eine Speicherabbildung gewährt hat, durchlaufen einzelne Lade- und Speicherzugriffe die Berechtigungsprüfungen der MMU; sie lösen nicht jeweils einen Systemaufruf aus.

Die vertrauenswürdige Rechenbasis (TCB) umfasst die Hardware, Firmware und privilegierte Software, von deren Korrektheit der Schutz abhängt. Dazu gehören CPU, Bootkette, Kernel und vertrauenswürdige Anmeldekomponenten. Treiber oder Dateisysteme in Server im Benutzermodus zu verlagern, kann den Kernelanteil dieser Basis verkleinern, wie es Mikrokernelkonzepte tun. Eine kompromittierte gewöhnliche Anwendung missbraucht ihre gewährten Rechte; eine kompromittierte vertrauenswürdige Komponente kann die Prüfungen selbst untergraben.

Virtueller Speicher übersetzt Adressen und schützt zugleich Programme. Ein Prozess kann die physischen Seitenrahmen erreichen, die seine aktive Seitentabelle nennt, und zwar mit den vom Kernel festgelegten Berechtigungen. Die privaten Seitenrahmen eines anderen Prozesses fehlen; gezielte Abbildungen gemeinsam genutzten Speichers sind eine ausdrückliche Ausnahme.

Prüfe jeden Speicherzugriff

Die Speicherverwaltungseinheit (MMU) prüft bei Zugriffen die Seitentabelleneinträge. Wichtige Berechtigungen sind präsent oder gültig, beschreibbar, für Benutzer zugänglich und ausführbar. Auf x86 unterscheidet U/S zwischen für Benutzer zugänglichen Seiten und Seiten mit ausschließlichem Kernelzugriff; NX oder XD verhindert die Ausführung. ARM nennt seine Ausführungsbeschränkung XN.

Ein Verstoß löst einen Seitenfehler aus. Der Fehler meldet eine fehlgeschlagene Hardwareprüfung; der Kernel entscheidet, ob dieser Fehlschlag erwartet und behebbar ist. Betrachte zwei Schreibzugriffe auf schreibgeschützte Seiten:

• Ein Prozess überschreibt eine Codeseite, die keine Copy-on-Write-Seite ist. Der Kernel behandelt dies als ungültigen Schreibzugriff und sendet normalerweise SIGSEGV.
• Nach fork() schreibt ein Prozess gemeinsam genutzte Daten, die als Copy-on-Write markiert sind. Der Kernel reserviert eine private Kopie, macht die Abbildung beschreibbar und versucht den Befehl erneut.

Beide Fehler gehen von einem Schutzbit aus. Die Verwaltungsdaten des Kernels erklären, warum die Abbildungen schreibgeschützt waren, und bestimmen die Reaktion. Ein Seitenfehler bedeutet daher nicht automatisch einen Absturz oder eine Anfrage, Daten von der Festplatte zu laden.

Schütze Kernelabbildungen in beide Richtungen

Herkömmliche Speicherlayouts bilden Kernelspeicher mit ausschließlichem Kernelzugriff in Prozessadressräume ab. Das erleichtert den Kerneleintritt und blockiert zugleich Lese- und Schreibzugriffe aus dem Benutzermodus. Der Meltdown-Angriff von 2018 zeigte, dass einige Prozessoren solche Daten durch spekulative Ausführung preisgeben konnten. Die Kernel-Seitentabellenisolation (KPTI) entfernt auf betroffenen Systemen die meisten Kernelabbildungen, während Benutzercode läuft.

Kernelcode muss auch davor geschützt werden, in benutzerkontrollierten Speicher umgeleitet zu werden. SMEP auf x86 verhindert die Ausführung von Benutzerseiten im Kernelmodus. SMAP blockiert Datenzugriffe im Kernelmodus auf Benutzerseiten, außer bei gezielt erlaubten Kopieroperationen. ARM bietet entsprechende Schutzmechanismen durch PXN und PAN. Diese Prüfungen verringern die Möglichkeiten eines Angreifers, einen Kernelfehler zum Ausführen von Code oder zum Bereitstellen gefälschter Kerneldaten zu nutzen.

Schreibgeschützter Zugriff schützt die Integrität, nicht die Geheimhaltung. Kann ein Prozess eine abgebildete Seite lesen, kann er ihren Inhalt erfahren, selbst wenn Schreibzugriffe fehlschlagen. Vertrauliche Daten müssen für diesen Prozess unzugänglich sein: Bilde sie nicht ab oder setze eine geeignete Grenze mit ausschließlichem Kernelzugriff durch.

Gib Geräten eine eigene Grenze

Anwendungen fordern Geräteoperationen gewöhnlich über einen Treiber an. Geräteregister sind normalerweise nur für den Kernel zugänglich. Ein berechtigter Prozess kann jedoch ausgewählte Abbildungen erhalten, wie bei Grafiktreibern oder Userspace-Ein-/Ausgabe unter Linux.

Ein Gerät mit direktem Speicherzugriff (DMA) liest oder beschreibt RAM, ohne diese Zugriffe durch die MMU der CPU zu leiten. CPU-Seitenberechtigungen allein können ein fehlerhaftes Gerät nicht daran hindern, die Seitenrahmen eines anderen Prozesses zu überschreiben. Eine IOMMU übersetzt und begrenzt Geräteadressen mit gerätespezifischen Abbildungen. Intel VT-d und AMD-Vi stellen diesen Mechanismus bereit.

Bei einem Gerät, das einer VM zugewiesen ist, begrenzt die IOMMU den DMA-Zugriff auf den dieser VM zugewiesenen Speicher. Auf CPU-Seite ist eine entsprechende Grenze nötig: Eine zweite Stufe der Seitenübersetzung bildet physische Gastadressen nur auf Seitenrahmen ab, die der Hypervisor erlaubt. Um eine Arbeitslast zu schützen, müssen sowohl CPU- als auch Gerätezugriffe abgedeckt werden.

Ein Fehler, der die Speichersicherheit verletzt, kann zu einem Angriff führen, wenn beschädigte Daten den Kontrollfluss des Programms ändern. Ein Pufferüberlauf auf dem Stack kann beispielsweise eine gespeicherte Rücksprungadresse überschreiben. Schutzmechanismen des Betriebssystems begrenzen, was ein Angreifer mit diesem Fehler tun kann; sie beheben den fehlerhaften Schreibzugriff nicht.

Trenne Daten von ausführbarem Code

Das NX-Bit markiert Datenseiten als nicht ausführbar. Windows nennt dies Data Execution Prevention (DEP). Das Einschleusen von Befehlen in einen Stackpuffer ist weniger nützlich, wenn ein Sprung dorthin einen Fehler auslöst.

W^X, schreibbar exklusiv oder ausführbar, ist strenger: Keine Seite ist gleichzeitig beschreibbar und ausführbar. DEP allein verbietet einem Programm nicht, eine solche Abbildung ausdrücklich anzufordern. Unter W^X schreibt ein Just-in-Time-Compiler erzeugten Code in beschreibbaren Speicher und ändert dann dessen Berechtigungen, bevor er ihn ausführt.

Ein Angreifer kann stattdessen vorhandene ausführbare Befehle wiederverwenden. Return-Oriented Programming (ROP) verkettet kurze Befehlsfolgen, die Gadgets heißen. Die Randomisierung des Adressraumlayouts (ASLR) ändert die Positionen von Stacks, Heaps, Bibliotheken und positionsunabhängigen Programmen, sodass Gadget-Adressen schwer vorherzusagen sind.

Wird die Basis einer Bibliothek gleichverteilt aus $2^{28}$ Positionen gewählt, gelingt ein blinder Rateversuch mit einer Wahrscheinlichkeit von 1 zu 268.435.456. Bei nur $2^8=256$ Positionen und einem Layout, das über Abstürze von Worker-Prozessen hinweg erhalten bleibt, braucht das Ausprobieren verschiedener Positionen höchstens 256 Versuche und durchschnittlich 128,5. Eine preisgegebene Adresse innerhalb einer bekannten Bibliothek verrät deren Basis und die Offsets der Gadgets in dieser Bibliothek. Ein getrennt randomisierter Stack kann weiterhin unbekannt bleiben.

Begrenze die Leistungen, die ein Angreifer anfordern kann

Seccomp-Filter unter Linux beschränken die Systemaufrufe, die ein Prozess ausführen darf. Einem Browserprozess zur Darstellung von Webseiten können beispielsweise Aufrufe zum Starten von Programmen oder zum direkten Öffnen von Dateien verweigert werden. Kindprozesse erben die Filter; sie lassen sich nicht entfernen, und spätere Filter können die Einschränkungen verschärfen. Ein übernommener Darstellungsprozess verfügt weiterhin über seine erlaubten Operationen. Ein Filter ist also eine Grenze für Leistungen und kein Beweis dafür, dass das Programm fehlerfrei ist. pledge von OpenBSD und die App Sandbox von macOS bieten ähnliche Einschränkungen.

Prüfe den Start und sichere Belege

Secure Boot prüft Signaturen entlang der Bootkette. Die Firmware prüft einen vertrauenswürdigen Bootloader; der Bootloader prüft den Kernel; der Kernel kann signierte Module verlangen. Eine veränderte Komponente ohne vertrauenswürdige Signatur wird zurückgewiesen. Das hilft, dauerhafte Änderungen an der Startsoftware zu verhindern, aber eine gültige Signatur beweist nicht, dass die Software keine Schwachstellen hat.

Measured Boot zeichnet Hashes geladener Komponenten auf, gewöhnlich mithilfe eines TPM. Diese Messwerte ermöglichen eine Attestierung: Eine andere Partei kann den gestarteten Zustand mit einem erwarteten Zustand vergleichen. Messen und das Verweigern des Starts sind unterschiedliche Operationen.

Die Überwachungsprotokollierung zeichnet Anmeldungen, fehlgeschlagene Authentifizierungen, verweigerte Berechtigungen, Kontoänderungen und privilegierte Aktionen wie sudo auf. Protokolle unterstützen die Erkennung und Rekonstruktion. Ein Angreifer, der einen Host kontrolliert, kann lokale Aufzeichnungen löschen. Geschützte Protokolle oder eine Protokollierung auf einem anderen Rechner erhalten daher Belege über diesen Host hinaus.

Angreifer können die Preisgabe einer Adresse, einen Fehler mit Speicherbeschädigung und einen Sandbox-Ausbruch kombinieren. Updates beseitigen die zugrunde liegenden Schwachstellen, die diese Schutzmechanismen bestehen lassen.

Eine erfolgreiche Anmeldung verbindet die Identität einer Person mit Anmeldeinformationen eines Prozesses, die der Kernel verwaltet. Authentifizierung prüft die behauptete Identität; Autorisierung entscheidet, was diese Identität tun darf. Ein Sicherheitssubjekt kann eine Person oder ein Dienstkonto sein; Prozesse handeln in seinem Auftrag.

Übertrage Identität in laufende Programme

Unix-artige Systeme identifizieren Benutzer anhand numerischer UIDs und Gruppen anhand von GIDs. /etc/passwd ordnet Namen UIDs, Home-Verzeichnissen und Shells zu. Der Kernel vergleicht die Nummern: Zwei Kontonamen mit einer UID sind für Zugriffsprüfungen eine Identität. UID 0 ist root und umgeht die meisten gewöhnlichen Berechtigungsprüfungen.

Windows nutzt Sicherheitskennungen (SIDs) für Benutzer und Gruppen. Das Zugriffstoken eines Prozesses hält seine Benutzer-SID, Gruppen-SIDs und Privilegien fest. Auf beiden Plattformen liefern die Anmeldeinformationen des laufenden Programms die Identität für spätere Entscheidungen.

Eine typische Passwortanmeldung unter Linux verläuft so:

1. Ein privilegierter Anmeldedienst wie login, sshd oder ein Displaymanager erhält die Anmeldeinformationen.
2. PAM prüft sie über konfigurierte Authentifizierungsmodule.
3. Der Dienst setzt die ergänzenden Gruppen und die GID des Benutzers und ändert dann die UID, um root aufzugeben.
4. Er startet die Shell. Kindprozesse erben diese Anmeldeinformationen über fork() und behalten sie normalerweise über execve() hinweg.

Die Reihenfolge ist wichtig. Gibt der Prozess root auf, bevor er Gruppen setzt, kann er möglicherweise seine geerbte privilegierte Gruppenliste nicht mehr ersetzen. Auch das Ändern der Gruppenzugehörigkeit eines Kontos schreibt die Anmeldeinformationen bereits laufender Prozesse nicht um; eine neue Anmeldesitzung erhält die neue Liste.

Verstehe einen kontrollierten Privilegwechsel

Ein Prozess hat eine reale UID, die normalerweise angibt, wer ihn gestartet hat, eine effektive UID, die für die meisten Zugriffsprüfungen verwendet wird, und eine gespeicherte Set-User-ID, die nach einer vorübergehenden Herabsetzung einen kontrollierten Wechsel zurück ermöglicht. Bei gewöhnlichen Programmen sind alle drei gleich.

Das root gehörende /usr/bin/passwd veranschaulicht Setuid. Sein Modus 4755, dargestellt als -rwsr-xr-x, macht root zur effektiven UID, wenn ein gewöhnlicher Benutzer es ausführt. Hat alice UID 1000, bleibt ihre reale UID 1000, während die effektive UID zu 0 wird. Das Programm kann /etc/shadow aktualisieren und nutzt die reale Identität des Aufrufers, um einzuschränken, wessen Passwort geändert werden darf. Eine ausführbare Setgid-Datei ändert entsprechend die effektive Gruppe.

Dieses kleine vertrauenswürdige Programm besitzt gefährliche Befugnisse. Ein Fehler kann Root-Rechte offenlegen, daher halten Systeme die Zahl der Setuid-Programme klein und geben Privilegien früh ab. Für einen Dienst, der nur einen Port mit niedriger Nummer benötigt, gewährt CAP_NET_BIND_SERVICE ein enger begrenztes Linux-Privileg als volle Root-Rechte.

Administriere, ohne eine Identität zu teilen

sudo authentifiziert den aufrufenden Benutzer, prüft, welche Befehle dieser als welche Zielidentität ausführen darf, und protokolliert die Nutzung. Die Regeln stehen gewöhnlich in /etc/sudoers. Individuelle Identitäten erhalten die persönliche Verantwortlichkeit, die beim Teilen eines Root-Passworts verloren geht. Unter Windows startet UAC die Programme eines Administrators normalerweise mit einem gefilterten Token und fragt für eine Rechteerhöhung um Zustimmung.

Alltägliche Anwendungen sollten mit gewöhnlichen Rechten laufen, und Dienste sollten eigene Konten wie www-data haben. Ein übernommener Dokumentbetrachter erbt dann diese eingeschränkten Anmeldeinformationen statt der vollen Befugnisse eines Administrators.

Ein Passwortprüfsystem muss ein korrektes Passwort erkennen, ohne eine wiederherstellbare Kopie zu speichern. Es speichert einen Passwort-Hash mit den Informationen, die zur Wiederholung der Prüfung nötig sind. Bei der Anmeldung wird der Hash aus dem eingegebenen Passwort erneut berechnet und das Ergebnis verglichen; der gespeicherte Hash wird nie entschlüsselt.

Schütze den gespeicherten Prüfwert

Unter Linux enthält /etc/shadow geschützte Passwort-Hashes. Die weithin lesbare Datei /etc/passwd enthält Kontoinformationen und ein x anstelle des Passworts. Ein Shadow-Passwortfeld hält eine Algorithmuskennung, Kostenparameter, einen Salt und den resultierenden Hash fest. $y$ bezeichnet yescrypt, das standardmäßig in Debian 11, Ubuntu 22.04, Fedora 35 und späteren Versionen verwendet wird; $6$ bezeichnet SHA-512-crypt.

Eine gestohlene Hashdatei ermöglicht einen Offlineangriff. Der Angreifer hasht Rateversuche auf separater Hardware ohne die Verzögerungen des Anmeldedienstes. Ein Brute-Force-Angriff zählt Zeichenfolgen auf; ein Wörterbuchangriff beginnt mit wahrscheinlichen Wörtern, geleakten Passwörtern und Varianten wie „Password1!“.

Bei genau acht Kleinbuchstaben sind ${26}^8=\mathrm{208.827.064.576}$ Zeichenfolgen möglich. Bei ${10}^{10}$ Rateversuchen pro Sekunde dauert das vollständige Durchsuchen etwa 21 Sekunden. Bei ${10}^4$ Rateversuchen pro Sekunde dauert es etwa $\mathrm{2,09}\times {10}^7$ Sekunden, ungefähr 242 Tage. Dies sind Zeiten für eine vollständige Suche, keine Garantien für ein einzelnes Passwort. Zwölf Kleinbuchstaben ergeben etwa $\mathrm{9,5}\times {10}^{16}$ Zeichenfolgen, selbst bei der schnelleren Rate ungefähr 110 Tage.

Erhöhe den Angriffsaufwand für jedes Konto

Ein Salt ist ein neuer Zufallswert, der neben jedem Passwort-Hash gespeichert wird. Er sorgt dafür, dass gleiche Passwörter unterschiedliche Hashes ergeben, und macht wiederverwendbare vorberechnete Tabellen unwirksam. Der Salt ist öffentlich; seine Aufgabe ist es, getrennten Aufwand für verschiedene Konten zu erzwingen.

Betrachte 1.000 Konten und eine Liste mit ${10}^6$ Rateversuchen, geprüft mit ${10}^4$ Hashes pro Sekunde. Ohne Salts dauert die einmalige Berechnung der Liste 100 Sekunden und kann für alle Konten genutzt werden. Eigene Salts erfordern ${10}^9$ Berechnungen, etwa ${10}^5$ Sekunden oder 27,8 Stunden. Ein häufiges Passwort kann dennoch nahe am Anfang der Liste gefunden werden.

Passwort-Hashing-Verfahren wie bcrypt, scrypt, yescrypt, Argon2 und PBKDF2 haben einen einstellbaren Rechenaufwand. Scrypt, yescrypt und Argon2 verursachen außerdem Speicheraufwand. Bei einer Anmeldung ist ein Bruchteil einer Sekunde hinnehmbar; eine große Ratekampagne wiederholt diesen Aufwand Millionen Mal. Einer einzelnen schnellen SHA-256-Berechnung fehlt dieser gezielte Aufwand.

Richte die Anmelderegeln auf Rateangriffe aus

NIST SP 800-63B-4 (2025) verlangt Salts von mindestens 32 Bit und einen Passwort-Hashing-Kostenfaktor, der so hoch wie praktisch möglich ist. Die Passwortrichtlinie verlangt mindestens 15 Zeichen bei reiner Passwortauthentifizierung oder mindestens acht, wenn das Passwort Teil einer MFA ist, und empfiehlt, mindestens 64 Zeichen zuzulassen.

Sie lehnt vorgeschriebene Mischungen wie eine Ziffer und ein Sonderzeichen sowie routinemäßig erzwungene Passwortänderungen ab. Sie verlangt, häufige oder kompromittierte Passwörter zu sperren, Online-Rateversuche zu begrenzen und bei erkennbarer Kompromittierung eine Änderung zu erzwingen. Online-Ratenbegrenzungen schützen den laufenden Dienst; langsames Hashing mit Salt schützt gestohlene Prüfwerte. Ein längeres Passwort, das vorhersehbar aus einer gängigen Liste gewählt wird, kann weiterhin schwach sein.

Passwörter beweisen Wissen. Andere Authentifikatoren belegen den Besitz eines Gegenstands oder ein körperliches Merkmal. Das Betriebssystem ordnet die authentifizierte Identität schließlich Prozessen zu, aber der Weg zu dieser Identität beeinflusst, wie leicht ein Angreifer den Benutzer nachahmen kann.

Kombiniere unterschiedliche Faktorarten

Die drei Faktorarten sind etwas, das du weißt, etwa ein Passwort oder eine PIN; etwas, das du besitzt, etwa ein Telefon, eine Smartcard oder einen Sicherheitsschlüssel; und etwas, das du bist, etwa ein Fingerabdruck. Mehrfaktorauthentifizierung (MFA) kombiniert unterschiedliche Arten. Ein Passwort und eine Sicherheitsfrage wiederholen den Wissensfaktor.

Zeitbasierte Einmalpasswörter (TOTP) nutzen ein gemeinsames Geheimnis und einen Zeitschritt, gewöhnlich 30 Sekunden, um auf einem Authentifikator und einem Server übereinstimmende Codes zu erzeugen. RFC 6238 definiert das Verfahren. Ein Code verfällt schnell, aber eine gefälschte Anmeldeseite kann einen frischen Code vor seinem Ablauf weiterleiten. App-Codes vermeiden SIM-Swapping; SMS-Codes hängen von der Kontrolle über die Telefonnummer ab und können bei deren Übernahme umgeleitet werden.

Beweise den Besitz, ohne den Schlüssel zu senden

Ein Public-Key-Authentifikator signiert eine neue Herausforderung mit einem privaten Schlüssel. Der Server prüft sie mit einem gespeicherten öffentlichen Schlüssel, der selbst nicht zum Signieren einer Anmeldung wiederverwendet werden kann. FIDO2-Sicherheitsschlüssel und Passkeys binden die Authentifizierung außerdem an die Identität der Website, sodass eine Antwort für eine gefälschte Seite nicht bei der echten authentifizieren kann. Auch ein gewöhnlicher SSH-Schlüssel beweist Besitz; man sollte aber nicht annehmen, dass er denselben Mechanismus zur Bindung an eine Website hat.

Die Speicherung verändert das Risiko. Gerätegebundene Schlüssel in einem Hardware-Sicherheitsschlüssel, TPM oder einer sicheren Enklave signieren innerhalb der Hardware, ohne den privaten Schlüssel preiszugeben. Synchronisierte Passkeys kopieren verschlüsseltes Schlüsselmaterial über ein Plattformkonto zwischen Geräten. Das erleichtert die Wiederherstellung, bezieht aber dieses Konto in die Vertrauensgrenze ein. Ein gewöhnlicher privater SSH-Schlüssel ist eine Datei, die durch Berechtigungen und optional eine Passphrase geschützt ist.

Interpretiere biometrische Fehler

Ein biometrisches System vergleicht gemessene Merkmale mit einem gespeicherten Referenzmuster. Es akzeptiert, wenn ein Ähnlichkeitswert einen Schwellenwert erreicht; ein jedes Mal identisches Bild ist nicht nötig.

Zwei akzeptierte Unberechtigte bei 10.000 Versuchen ergeben eine FAR von 0,02 %. Dreißig Ablehnungen bei 1.000 Versuchen Berechtigter ergeben eine FRR von 3 %. Ein höherer Ähnlichkeitsschwellenwert senkt die FAR und erhöht die FRR. Eine strengere Übereinstimmung verringert erfolgreiche Identitätsvortäuschungen, macht aber erneute Versuche Berechtigter häufiger nötig.

Ein bekannt gewordenes biometrisches Merkmal lässt sich nicht wie ein Passwort ändern, und Sensoren brauchen Schutz gegen Fotos oder kopierte Fingerabdrücke. Ein zweckmäßiges Konzept nutzt Biometrie lokal, um einen geschützten Schlüssel zu entsperren, und sendet nur eine Signatur an den Server.

Authentifiziere auch Prozesse

Bei einer lokalen Unix-Domain-Verbindung bezieht SO_PEERCRED unter Linux die Anmeldeinformationen der Gegenstelle vom Kernel, statt einem vom Client gesendeten Namen zu vertrauen. Zwischen Rechnern nutzen Dienste Schlüssel, Zertifikate oder Token, die unter dem Dienstkonto mit eingeschränktem Zugriff gespeichert sind. Nach der Anmeldung nutzen gewöhnliche Zugriffsprüfungen des Betriebssystems die UID oder das Zugriffstoken; sie fragen nicht, ob der Benutzer ein Passwort eingegeben oder einen Schlüssel berührt hat.

Eine Zugriffsentscheidung hat drei Teile: Ein Subjekt bittet darum, eine Operation auf einem Objekt auszuführen. Das Subjekt ist gewöhnlich ein Prozess, der für ein Sicherheitssubjekt handelt; zu den Objekten gehören Dateien, Geräte und andere Prozesse. Eine Zugriffsmatrix stellt die Rechte in Zellen dar, mit Subjekten als Zeilen und Objekten als Spalten.

Speichere dieselben Rechte auf zwei Arten

Angenommen, alice darf report.txt lesen und schreiben, bob darf die Datei nur lesen, und der Sicherungsdienst darf sowohl report.txt als auch payroll.db lesen. Bob darf payroll.db außerdem lesen und schreiben. Alice und bob dürfen den Drucker nutzen; der Sicherungsdienst darf es nicht. Die meisten Zellen in der viel größeren Matrix eines realen Systems sind leer.

Eine Zugriffskontrollliste (ACL) speichert eine Spalte bei ihrem Objekt. Die Liste von report.txt nennt alice, bob und backup mit ihren jeweiligen Rechten. Eine Capability-Liste speichert eine Zeile beim Subjekt. Bob besitzt Token zum Lesen des Berichts, zum Lesen und Schreiben der Gehaltsdaten und zum Nutzen des Druckers.

Eine Capability bezeichnet sowohl ein Objekt als auch erlaubte Operationen und kann von ihrem Besitzer weder gefälscht noch erweitert werden. Autorisiertes Kopieren und Delegieren sind möglich. Der Kernel kann das eigentliche Token halten, während Benutzercode einen Index besitzt; ein anderer Ansatz schützt ein Token kryptografisch.

Verfolge einen Deskriptor nach dem Öffnen

Unix kombiniert beide Ansätze. open() prüft den Aufrufer anhand der Dateiberechtigungen und gibt dann einen Dateideskriptor zurück, der den gewährten Zugriff festhält. Spätere Lese- und Schreibzugriffe prüfen dieses geöffnete Handle. Ein Kindprozess kann es über fork() erben, oder ein Prozess kann es über einen Unix-Domain-Socket empfangen.

Alice öffnet app.log zum Schreiben. Der Eigentümer ändert den Modus auf 444. Über den bereits geöffneten Deskriptor kann alice weiterhin schreiben; ein neuer Versuch, die Datei zum Schreiben zu öffnen, trifft auf den neuen Modus. Eine Aktualisierung der ACL für zukünftige Öffnungen widerruft nicht jede bereits ausgegebene Capability. Windows-Handles folgen demselben allgemeinen Muster.

Capsicum von FreeBSD macht dies für die Einschränkung von Prozessen nutzbar. Nach cap_enter() kann ein Prozess keinen beliebigen absoluten Pfad öffnen. Er kann über bestehende Deskriptoren arbeiten, Deskriptoren empfangen und openat() unterhalb eines Verzeichnisdeskriptors nutzen, den er besitzt. Ein Elternprozess kann einem Worker daher genau die Dateien geben, die er benötigt. Capability-basierte Kernel wie seL4 und Fuchsia erweitern die Idee auf Kernelobjekte allgemein.

Unterscheide die andere Bedeutung von Capability unter Linux

Linux-Capabilities teilen die Privilegien von root in Kategorien auf. CAP_NET_BIND_SERVICE erlaubt das Binden von Ports mit niedrigen Nummern; CAP_DAC_OVERRIDE umgeht gewöhnliche Dateizugriffsprüfungen. Diese Privilegien bezeichnen kein bestimmtes einzelnes Objekt und unterscheiden sich daher von einer Capability im Sinne der Zugriffsmatrix. Ein einzelnes Linux-Privileg kann eine Klasse von Operationen an vielen Objekten erlauben.

Unix-Berechtigungen ordnen dem Eigentümer, der Eigentümergruppe und allen anderen Rechte zu. Um über einen Zugriff zu entscheiden, bestimme zuerst die Operation und das betreffende Objekt. Dateiinhalt zu lesen, ein Verzeichnis zu durchqueren und einen Namen zu löschen erfordert unterschiedliche Berechtigungen.

Entschlüssele und wähle die Bits

Lesen ist 4, Schreiben 2 und Ausführen 1. Addiere diese Werte für jede Klasse: 754 bedeutet rwxr-xr--; 640 bedeutet rw-r-----. chmod 640 notes.txt setzt einen Modus, während chmod g+w,o-r notes.txt ausgewählte Bits ändert. Der Eigentümer oder root darf den Modus ändern; ein Eigentümerwechsel benötigt Root-Befugnisse, unter Linux dargestellt durch CAP_CHOWN.

Der Kernel wählt die erste zutreffende Klasse: Eigentümer, wenn die effektive UID übereinstimmt, andernfalls Gruppe, wenn eine Gruppe des Prozesses übereinstimmt, sonst andere. Er kombiniert keine Klassen und versucht keine großzügigere Klasse erneut. Alice gehört eine Datei mit Modus 077: Ihre Eigentümerbits sind leer, daher kann sie die Datei nicht lesen, obwohl Gruppe und andere volle Rechte haben. Als Eigentümerin kann sie den Modus dennoch ändern.

Root umgeht normalerweise Lese- und Schreibprüfungen. Um eine reguläre Datei unter den gewöhnlichen benutzerbestimmten Linux-Prüfungen auszuführen, muss mindestens ein Ausführungsbit gesetzt sein. Systembestimmte Regeln können weitere Einschränkungen auferlegen.

Interpretiere Verzeichnis- und Spezialbits

Die Leseberechtigung für ein Verzeichnis erlaubt das Auflisten von Namen; Ausführen erlaubt das Durchqueren und Nachschlagen; Schreiben zusammen mit Ausführen erlaubt das Erstellen, Löschen und Umbenennen von Einträgen. Das Entfernen eines Namens ändert sein Verzeichnis. Daher kann eine Person mit den nötigen Verzeichnisrechten eine Datei mit Modus 000 löschen.

Setuid fügt dem Modus einer ausführbaren Datei oktal 4000 hinzu und ändert bei der Ausführung die effektive Benutzeridentität. Setgid fügt 2000 hinzu und ändert entsprechend die Gruppe; auf einem Verzeichnis sorgt es dafür, dass neue Dateien die Gruppe des Verzeichnisses erben. Das Sticky-Bit fügt 1000 hinzu. Ein Verzeichnis wie /tmp mit Modus 1777 erlaubt das Löschen oder Umbenennen nur dem Dateieigentümer, dem Verzeichniseigentümer oder einem privilegierten Prozess. Die gewöhnlichen Verzeichnisberechtigungen sind weiterhin erforderlich.

Entferne Bits beim Erstellen von Dateien

Eine umask löscht Bits aus dem von einem Programm angeforderten Modus. Das ist eine Bitoperation, keine oktale Subtraktion. Bei den üblichen Anforderungen von 666 für Dateien und 777 für Verzeichnisse gilt:

Eine umask kann keine Ausführungsrechte hinzufügen, die in der Dateianforderung fehlten.

Lies erweiterte Zugriffslisten

POSIX-ACLs ergänzen benannte Benutzer und Gruppen. setfacl -m u:bob:r report.txt gibt bob einen benannten Leseeintrag; getfacl zeigt ihn an und ls -l markiert die erweiterte ACL mit +. Die ACL-Maske begrenzt benannte Benutzer, benannte Gruppen und die Eigentümergruppe, sodass ein benannter Eintrag mehr Rechte anzeigen kann, als tatsächlich wirksam sind.

Windows NTFS nutzt einen Sicherheitsdeskriptor mit einer Eigentümer-SID und einer DACL aus geordneten erlaubenden oder verweigernden ACEs. Die Auswertung stoppt, wenn ein angefordertes Recht verweigert wird oder alle angeforderten Rechte gewährt wurden; nicht gewährte Rechte werden verweigert. Die bevorzugte Reihenfolge setzt explizite Einträge vor geerbte, innerhalb jeder Gruppe stehen verweigernde vor erlaubenden Einträgen. Eine explizite Erlaubnis kann daher eine Anfrage entscheiden, bevor eine geerbte Verweigerung erreicht wird. Eine separate SACL wählt Zugriffsereignisse für die Überwachungsprotokollierung aus.

Verschiedene Zugriffskontrollmodelle beantworten unterschiedliche Verwaltungsfragen. Wer darf Zugriff gewähren? Kann ein kompromittiertes Programm Daten eines Benutzers weitergeben? Wie kann ein Administrator die Rechte vieler Beschäftigter ändern, ohne jede Datei zu bearbeiten? Ein Betriebssystem kann mehrere Modelle auf dieselbe Anfrage anwenden.

Unterscheide Eigentümerentscheidung und systemweite Regeln

Bei der benutzerbestimmten Zugriffskontrolle (DAC) entscheidet der Eigentümer eines Objekts, wer es nutzen darf. Unix-Modi und ACLs sind vertraute Mechanismen. Die Schwäche besteht darin, dass ein bösartiges Programm, das als der Benutzer handelt, dessen Rechte ausüben kann, einschließlich des Kopierens lesbarer Daten an einen anderen Ort.

Bei der systembestimmten Zugriffskontrolle (MAC) begrenzen systemweite Regeln eines Administrators den Zugriff unabhängig von den Wünschen des Eigentümers. Der Kernel wendet MAC zusätzlich zu DAC an. Beide Prüfungen müssen den Zugriff erlauben, sodass ein großzügiger Dateimodus eine systembestimmte Verweigerung nicht außer Kraft setzt.

Das Bell-LaPadula-Modell schützt die Vertraulichkeit durch geordnete Stufen und zwei Regeln: nicht nach oben lesen und nicht nach unten schreiben. Ein Prozess auf der Stufe geheim darf vertrauliche Daten lesen und an ein streng geheimes Ziel schreiben. Er darf keine streng geheimen Daten lesen oder vertrauliche Daten schreiben. Ein Programm kann Informationen nicht einfach durch Lesen und erneutes Schreiben von geheim nach vertraulich verschieben. Biba kehrt die Lese- und Schreibrichtungen um, um die Integrität zu schützen.

Schränke einen Dienst auch als root ein

SELinux kennzeichnet Dateien mit Typen und führt Prozesse in Domänen aus. Regeln benennen, welche Domäne welche Operationen auf jedem Typ ausführen darf; nicht aufgeführter Zugriff wird verweigert. Ein Webserver in httpd_t darf mit httpd_sys_content_t gekennzeichnete Seiten lesen, während ihm der Zugriff auf user_home_t verwehrt bleibt, selbst wenn gewöhnliche Unix-Modi das Lesen erlauben. ls -Z zeigt Kennzeichnungen an.

Im durchsetzenden Modus blockiert und protokolliert SELinux Verstöße. Im toleranten Modus protokolliert es, ohne zu blockieren. Root in einer eingeschränkten Domäne muss weiterhin die durchgesetzten Regeln erfüllen. UID 0 und uneingeschränkter Zugriff sind daher unterschiedliche Aussagen.

AppArmor schränkt Programme mit Profilen ein, die auf Dateipfaden und erlaubten Capabilities beruhen. Es wird häufig unter Ubuntu und SUSE eingesetzt. SELinux und AppArmor wirken bei Sicherheitsentscheidungen über Schnittstellen der Linux-Sicherheitsmodule (LSM). Android kombiniert App-spezifische UIDs mit SELinux; Apple-Systeme nutzen ebenfalls Sandbox-Profile für Anwendungen.

Weise Tätigkeiten statt einzelner Rechte zu

Bei der rollenbasierten Zugriffskontrolle (RBAC) sind Berechtigungen Rollen zugeordnet, und Benutzer erhalten Rollenzugehörigkeiten. Wechselt eine Person die Tätigkeit, werden Zugehörigkeiten geändert statt vieler unabhängiger Objektberechtigungen.

Angenommen, 50 Beschäftigte benötigen jeweils 20 Berechtigungen. Die direkte Zuweisung braucht 1.000 Benutzer-Berechtigungs-Verknüpfungen. Haben fünf Rollen jeweils 20 Berechtigungen und jeder Beschäftigte eine Rolle, benötigt die Verwaltung 50 Benutzer-Rollen-Verknüpfungen und 100 Rollen-Berechtigungs-Verknüpfungen: insgesamt 150. Die Einsparung entsteht durch gemeinsame Tätigkeitsmuster, nicht durch das Löschen benötigter Berechtigungen.

Als Rollen genutzte Windows-Gruppen und gruppenbasierte sudo-Regeln setzen dieses Muster um. DAC eignet sich für vom Eigentümer verwaltete Dateien, MAC schränkt Dienste nach zentral durchgesetzten Regeln ein und RBAC organisiert administrative Zuweisungen. Ein Dienst kann seine Tätigkeitsrechte über eine Rolle erhalten, während DAC und MAC beide seinen tatsächlichen Dateizugriff prüfen.

Eine virtuelle Maschine (VM) stellt einem vollständigen Betriebssystem scheinbar einen eigenen Computer zur Verfügung. Dieses Betriebssystem ist das Gastbetriebssystem. Der physische Computer ist der Host, und der Hypervisor, auch Virtual Machine Monitor (VMM), weist den Gastbetriebssystemen reale Prozessorzeit, Speicher und Geräte zu.

Bewahre das Verhalten und behalte die Kontrolle

Das Modell von Popek und Goldberg aus dem Jahr 1974 nennt drei Eigenschaften. Äquivalenz bedeutet, dass Programme sich wie auf einem realen Rechner verhalten, abgesehen von Zeitverhalten und verfügbaren Ressourcen. Ressourcenkontrolle bedeutet, dass der Hypervisor die Kontrolle über die Hardware behält. Effizienz bedeutet, dass die meisten Gastbefehle direkt auf dem Prozessor laufen.

Der Hypervisor plant virtuelle CPUs (vCPUs) auf physischen Kernen ein. Ein Maschinenwechsel sichert den vollständigen Ausführungszustand einer VM einschließlich privilegierter Register und Interrupteinstellungen und stellt dann den einer anderen wieder her. Ein Gastbetriebssystem sieht seinen eigenen Zustand, auch wenn es sich einen physischen Kern mit anderen Gastbetriebssystemen teilt.

KVM macht den Linux-Kernel selbst zum Hypervisor und wird gewöhnlich als Typ 1 eingeordnet. Ein vollständiger Linux-Host bleibt verfügbar, wodurch die einfache Unterscheidung zweier Typen weniger eindeutig wird. Um den Schutz zu beurteilen, bestimme, welche Komponente die CPU- und Speichervirtualisierung tatsächlich kontrolliert.

Nutze die Abstraktion einer Maschine

Serverkonsolidierung führt wenig ausgelastete Systeme zusammen. Zwölf Server, die jeweils durchschnittlich 5 % eines Computers mit acht Kernen nutzen, benötigen zusammen 60 % eines solchen Computers. Dieser Durchschnitt legt nahe, dass eine Konsolidierung möglich ist. Gleichzeitige Spitzen sowie der Bedarf an RAM und Geräten erfordern aber weiterhin Reserven.

Ein Snapshot speichert den Zustand einer VM zur späteren Wiederherstellung. Das bloße Kopieren eines Festplattenimages erfasst weder eine laufende CPU noch ihren Speicher. Livemigration überträgt eine laufende VM auf einen anderen Host, indem sie den Speicher kopiert und die Ausführung mit einer kurzen Pause umschaltet. Diese Vorgänge sind möglich, weil der Maschinenzustand des Gastbetriebssystems als Daten dargestellt wird, die der Hypervisor verwaltet.

VMs unterstützen auch das Testen alter Systeme, die Trennung miteinander unverträglicher Software und das Ausführen unterschiedlicher Betriebssysteme auf kompatibler Hardware. In VMs kann ein Windows-Gastbetriebssystem neben einem Linux-Gastbetriebssystem laufen, jeweils mit eigenem Kernel. Cloud-Serverinstanzen nutzen häufig diese Grenze.

Unterscheide Virtualisierung von vollständiger Emulation

Ein Emulator kann einen Befehlssatz für einen anderen Prozessor interpretieren oder übersetzen, etwa ARM-Code auf x86. Hardwarevirtualisierung führt Gastbefehle normalerweise direkt auf einem kompatiblen Prozessor aus und greift bei sensitiven Ereignissen ein. Das erklärt sowohl ihre Geschwindigkeit als auch ihren Bedarf an CPU-Unterstützung.

Getrennte Gastkernel bilden eine nützliche Grenze: Die Übernahme eines Gastkernels gibt nicht unmittelbar Kontrolle über den Hostkernel. Die Grenze hängt weiterhin von korrektem Hypervisor- und Gerätemodellcode ab. Ein VM-Ausbruch nutzt eine Schwachstelle in dieser Ebene aus, während ein Seitenkanal über gemeinsam genutzte Hardware Daten preisgeben kann, ohne gewöhnlichen Speicherzugriff zu gewähren. Eine VM verringert die Schnittstellen, die einem nicht vertrauenswürdigen Gastbetriebssystem zugänglich sind; gemeinsam genutzte Hardware wird dadurch nicht unfehlbar.

Ein Gastkernel erwartet, seine Maschine zu kontrollieren. Der Hypervisor muss diesen Eindruck bewahren, ohne die Kontrolle über den realen Computer abzugeben. Die CPU-Virtualisierung lässt gewöhnliche Gastbefehle direkt laufen und fängt Operationen ab, die eine Änderung des Zustands der virtuellen Maschine erfordern.

Wende Trap-and-Emulate auf den virtuellen Zustand an

Beim klassischen Trap-and-Emulate werden dem Gastkernel Privilegien entzogen. Sein Versuch, ein Seitentabellenregister zu laden oder eine Trap-Tabelle einzurichten, löst einen Trap zum Hypervisor aus. Der Hypervisor aktualisiert das virtuelle Register oder die virtuelle Tabelle des Gastbetriebssystems und setzt die Ausführung fort. Er lässt das Gastbetriebssystem nicht die realen Kontrollstrukturen des Hypervisors ersetzen.

Ein Systemaufruf des Gastbetriebssystems kann bei diesem Konzept mehrere Übergänge erfordern. Die Gastanwendung löst einen Trap in die reale Behandlungsroutine des Hypervisors aus. Der Hypervisor überträgt die Ausführung mit verringerten Privilegien an die aufgezeichnete Behandlungsroutine des Gastkernels. Bei der Rückkehr des Gastkernels löst dieser privilegierte Rücksprung erneut einen Trap aus; der Hypervisor führt die tatsächliche Rückkehr zur Gastanwendung zu Ende.

Die Bedingung von Popek und Goldberg für dieses Verfahren lautet, dass jeder sensitive Befehl privilegiert sein muss. Sensitiv bedeutet, dass er die Maschinenkonfiguration ändert oder sich abhängig von der Privilegstufe anders verhält. Privilegiert bedeutet, dass er außerhalb des am stärksten privilegierten Modus einen Trap auslöst. Stillschweigende Unterschiede lassen sich nicht emulieren, wenn der Hypervisor nie von ihnen erfährt.

Verstehe das Hindernis beim klassischen x86

Die Analyse von Robin und Irvine aus dem Jahr 2000 identifizierte 17 sensitive, nicht privilegierte x86-Befehle. Beispielsweise kann POPF mit ausreichenden Privilegien das Flag zur Interruptfreigabe wiederherstellen, lässt es bei verringerten Privilegien aber stillschweigend unverändert. Ein Gastbetriebssystem mit verringerten Privilegien kann glauben, es habe Interrupts abgeschaltet, obwohl kein Trap den Hypervisor veranlasst hat, seinen virtuellen Interruptzustand zu aktualisieren.

Drei Ansätze lösen dieses Problem:

VMware nutzte 1999 Binärübersetzung; Xen nutzte 2003 Paravirtualisierung. Intel VT-x kam 2005 und AMD-V 2006. Gewöhnliche Gastanwendungen können weiterhin direkt laufen, wenn Kernelcode Übersetzung oder Hypercalls benötigt.

Trenne Ringnummer und Virtualisierungsmodus

Mit Intel VT-x läuft der Hypervisor im VMX-Root-Betrieb und ein Gastbetriebssystem im Non-Root-Betrieb. Der Gastkernel kann dort Ring 0 nutzen. Ring 0 in einem Gastbetriebssystem bedeutet keine Kontrolle über den physischen Host.

Konfigurierte Ereignisse verursachen einen VM-Exit, der den vCPU-Zustand in einer Kontrollstruktur wie der VMCS sichert. Der Hypervisor behandelt das Ereignis und setzt die Ausführung über einen VM-Entry fort. Viele Systemaufrufe können vollständig innerhalb des Gastbetriebssystems bleiben. ARM nutzt EL2 für den Hypervisor; RISC-V bietet eine Hypervisor-Erweiterung.

Führt ein Gastbetriebssystem HLT aus und ist dieses Ereignis für einen VM-Exit konfiguriert, markiert der Hypervisor seine vCPU als wartend und plant andere Arbeit ein, bis ein virtueller Interrupt eintrifft. Der physische Kern muss nicht untätig bleiben. VM-Exits und VM-Entrys kosten weiterhin Zeit, typischerweise Hunderte bis Tausende Takte. Daher bleiben Bündelung und paravirtuelle Schnittstellen wertvoll.

Eine Gastanwendung nutzt eine virtuelle Gastadresse. Ihr Kernel übersetzt diese in eine physische Gastadresse, die der Sicht des Gastbetriebssystems auf den RAM entspricht. Der Hypervisor bildet diese Adresse dann auf eine physische Hostadresse oder Maschinenadresse ab. Jedes Gastbetriebssystem kann annehmen, sein RAM beginne bei null, während es unterschiedliche reale Seitenrahmen nutzt.

Behalte den Seitenoffset bei

Verwende 4-KiB-Seiten. Das Gastbetriebssystem bildet die virtuelle Seite 2 auf Gastseitenrahmen 7 ab; der Hypervisor bildet Gastseitenrahmen 7 auf Maschinenseitenrahmen 42 ab. Für die Adresse 0x2ABC gilt:

1. Teile sie in Seite 2 und Offset 0xABC.
2. Ersetze Seite 2 durch Gastseitenrahmen 7. Das ergibt 0x7ABC.
3. Ersetze Gastseitenrahmen 7 durch Maschinenseitenrahmen 42, hexadezimal 0x2A.
4. Behalte den Offset bei. Das ergibt die Maschinenadresse 0x2AABC, also 174.780 Byte ab Adresse null.

Nur die Seitennummer ändert sich. Die physische Gastadresse als reale RAM-Adresse zu behandeln, würde die Zuweisungs- und Isolationsentscheidung des Hypervisors umgehen.

Vergleiche Software- und Hardwareübersetzung

Schattenseitentabellen bilden virtuelle Gastseiten direkt auf Maschinenseitenrahmen ab. Die reale MMU nutzt diese vom Hypervisor erstellten Tabellen. Der Hypervisor schützt die Seiten mit Gastseitentabellen vor Schreibzugriffen und fängt Änderungen und Wechsel der Gasttabellen ab, damit seine Schattentabellen konsistent bleiben. Häufige Adressraumwechsel des Gastbetriebssystems verursachen daher zusätzliche Traps.

Bei der verschachtelten Seitenverwaltung, Intel EPT oder AMD NPT, erhält die MMU beide Stufen. Die Hardware durchläuft die Gasttabellen und die Tabellen für die Übersetzung von physischen Gastadressen in Maschinenadressen. Aktualisierungen der Gastseitentabellen müssen nicht mehr alle per Software abgefangen werden. Der TLB speichert die kombinierte endgültige Übersetzung zwischen.

Ein Cache-Fehlzugriff kann dennoch aufwendig sein. Bei vier Ebenen auf jeder Stufe benötigt jeder der vier Gasttabelleneinträge vier Zugriffe auf verschachtelte Tabellen plus den Eintrag selbst: 20 Zugriffe. Die Übersetzung der endgültigen physischen Gastadresse der Daten fügt vier weitere hinzu. Das ergibt 24 Übersetzungszugriffe vor dem Datenzugriff. Große Speicherseiten und Seitentabellendurchlauf-Caches verringern diesen Aufwand im ungünstigsten Fall ohne zwischengespeicherte Einträge.

Gewinne Speicher mit begrenztem Wissen über das Gastbetriebssystem zurück

Speicherüberbuchung sagt insgesamt mehr Gastspeicher zu, als der Host besitzt. Vier VMs mit je 16 GiB ergeben 64 GiB auf einem Host mit 48 GiB. Das funktioniert nur, solange ihr aktiver Bedarf gedeckt werden kann; werden alle stark ausgelastet, wird Speicherrückgewinnung oder Auslagerung nötig.

Ein Balloon-Treiber innerhalb eines Gastbetriebssystems reserviert auf Anfrage des Hypervisors Seiten. Das Gastbetriebssystem wählt aus, was es freigibt, während der Hypervisor die Maschinenseitenrahmen hinter den Balloon-Seiten zurückgewinnt. Das verringert die Informationslücke: Das Gastbetriebssystem weiß, welche Daten wichtig sind, während der Hypervisor Zuweisungen sieht, ohne deren volle Bedeutung zu kennen.

Gemeinsame Seitennutzung, etwa Linux KSM, führt identische Seiten zu einer schreibgeschützten Kopie zusammen und trennt sie bei einem Schreibzugriff wieder. Auslagerung durch den Hypervisor bietet eine weitere Ausweichmöglichkeit, kann aber schlecht auswählen, weil ihm das Wissen des Gastbetriebssystems fehlt. Auch ein an die VM durchgereichtes Gerät braucht eine IOMMU, um seine DMA-Adressen zu übersetzen und zu begrenzen.

Das gemeinsame Nutzen identischer Seiten durch verschiedene Kunden hat einen Nachteil für die Vertraulichkeit: Die Dauer von Copy-on-Write kann verraten, ob ein anderes Gastbetriebssystem dieselben Daten besitzt. Cloud-Anbieter deaktivieren diese kundenübergreifende Nutzung daher häufig, obwohl sie Speicher spart.

Eine VM benötigt neben CPU-Zeit und RAM auch Speichergeräte, Netzwerkverbindungen und andere Geräte. Die Geräteschnittstelle beeinflusst Kompatibilität, Leistung und den Code, den ein nicht vertrauenswürdiges Gastbetriebssystem erreichen kann. Eine schnelle Schnittstelle und eine kleine vertrauenswürdige Schnittstelle sind verwandte Entwurfsentscheidungen, aber nicht dieselbe Eigenschaft.

Wähle, wie das Gastbetriebssystem ein Gerät erreicht

Ein Hilfsprogramm wie QEMU kann eine Intel-e1000-Netzwerkkarte emulieren. Der gewöhnliche Gasttreiber beschreibt vertraute Register; das Hilfsprogramm setzt die Wirkung um. Häufige Registerzugriffe können viele VM-Exits und Softwareoperationen verursachen.

Ein virtio-Treiber tauscht Anfragen dagegen über Warteschlangen im gemeinsam genutzten Speicher aus. Er kann mehrere Operationen einreihen und das Backend einmal benachrichtigen. Vmxnet3 von VMware und VMBus-Geräte von Hyper-V folgen ähnlichen virtualisierungsbewussten Konzepten. Ein paravirtueller Gerätetreiber bedeutet nicht, dass der gesamte Gastkernel paravirtuelle CPU-Operationen nutzen muss.

Bei der Gerätedurchreichung besitzt das Gastbetriebssystem ein physisches Gerät oder eine virtuelle SR-IOV-Funktion. Die IOMMU begrenzt DMA auf den Speicher der VM. Durchreichung verringert die Vermittlung durch Software, aber die Übertragung des Gerätezustands auf einen anderen Host kann die Livemigration erschweren.

Behandle virtuelle Festplatten als verwalteten Zustand

Eine virtuelle Festplatte ist häufig eine Hostdatei, etwa im Format qcow2, VMDK oder VHDX, oder ein Speichervolume. Copy-on-Write-Images lassen viele Gastbetriebssysteme eine Basis teilen und zugleich getrennte Änderungen aufzeichnen. Snapshots können den Festplattenzustand kostengünstig sichern; ein vollständiger Snapshot einer laufenden VM benötigt auch deren Ausführungs- und Speicherzustand. Klonen und Migration beruhen darauf, dass der Hypervisor diese Darstellungen verwalten kann.

Finde die Grenze, die ein Angreifer überwinden muss

Ein kompromittierter Gastkernel kontrolliert bereits diese VM, aber um den Host zu erreichen, ist ein VM-Ausbruch oder ein anderes Versagen der Grenze nötig. Die VENOM-Schwachstelle von 2015 betraf den emulierten Diskettencontroller von QEMU und konnte ermöglichen, Gastcode im QEMU-Prozess des Hosts auszuführen. Läuft die Geräteemulation in einem separaten Prozess innerhalb einer Sandbox, begrenzt das die Befugnisse, die durch einen solchen Fehler zugänglich werden.

Gemeinsam genutzte CPU-Caches, Sprungvorhersagen und Speicherbusse schaffen ebenfalls Seitenkanäle. Spectre und L1TF zeigten, dass sich Isolation nicht allein anhand von Seitenabbildungen beurteilen lässt. Gegenmaßnahmen umfassen Prozessor- und Mikrocode-Updates, das Löschen relevanter Zustände zwischen Gastbetriebssystemen und den Verzicht darauf, verschiedene Kunden gleichzeitig auf den Hardwarethreads eines Kerns einzuplanen.

Confidential Computing, darunter AMD SEV-SNP und Intel TDX, schützt Gastspeicher mit hardwareverwahrten Verschlüsselungsschlüsseln vor dem Hypervisor und unterstützt die Attestierung der gestarteten Umgebung. Es erweitert die Vertrauensgrenze gegenüber einem kompromittierten Host oder Betreiber. Es beseitigt nicht jeden Seitenkanal oder jede Möglichkeit, mit der ein Host den Dienst unterbrechen kann. Die Sicherheit einer VM hängt weiterhin vom Hypervisor, den Geräteschnittstellen, der Hardware und ihrer Konfiguration ab.

Ein Linux-Container ist eine Gruppe von Prozessen, die den Hostkernel mit eingeschränkten Sichten und Privilegien nutzen. Er hat keinen separaten Kernel und keinen emulierten Computer. Namensräume geben Prozessen eigene Instanzen von Ressourcen, die andernfalls global wären.

Ordne jedem Namensraum seine Sicht zu

clone() mit Namensraum-Flags erzeugt einen Kindprozess in ausgewählten neuen Namensräumen. unshare() trennt den Namensraumkontext, und setns() tritt über einen Deskriptor, etwa einen aus /proc/1234/ns/net geöffneten, einem bestehenden Namensraum bei. Eine erneute PID-Zuordnung wirkt sich auf spätere Kindprozesse aus, ohne den Aufrufer zu verschieben. Bei Zeitnamensräumen bereitet unshare(CLONE_NEWTIME) ebenfalls einen Namensraum für spätere Kindprozesse vor; setns() kann den Aufrufer in einen bestehenden Zeitnamensraum versetzen. Zeitnamensräume werden mit unshare() erzeugt.

Daher nutzt unshare --pid --fork --mount-proc bash die Option --fork, um die Shell innerhalb des neuen PID-Namensraums zu erzeugen. Diese Shell ist dort PID 1, selbst wenn ihre Host-PID 48213 ist. PID 1 übernimmt verwaiste Prozesse; endet sie, beendet der Kernel die übrigen Prozesse des Namensraums. Prozesse in einem übergeordneten Namensraum können untergeordnete Prozesse sehen, während Prozesse innerhalb eines PID-Namensraums nicht nach außen in übergeordnete PID-Namensräume sehen können.

Trenne Dateien und Netzwerk

Ein Mount-Namensraum gibt eine eigene Einhängeliste. Eine Laufzeitumgebung stellt einen Dateibaum zusammen und macht ihn mit pivot_root zum Wurzelverzeichnis. Ein Container kann /etc und /usr einer anderen Linux-Distribution nutzen und dennoch den Hostkernel aufrufen. chroot allein ändert lediglich den Ausgangspunkt der Pfadauflösung; gegenüber einem privilegierten Prozess ist es keine sichere Grenze.

Ein neuer Netzwerknamensraum hat eine Loopback-Schnittstelle. Eine Laufzeitumgebung kann ihn über ein Veth-Paar verbinden, wobei ein Endpunkt innerhalb liegt und der andere mit einer Host-Bridge verbunden ist. Getrennte Stacks lassen zwei Container beide an Port 80 lauschen, ohne um den Port eines Namensraums zu konkurrieren.

Übersetze Identitäten über einen Benutzernamensraum hinweg

Eine Zeile in /proc/<pid>/uid_map führt die erste interne Kennung, die erste externe Kennung und die Bereichslänge auf. Die Zeile 0 100000 65536 bildet die internen Kennungen 0–65535 auf die Hostkennungen 100000–165535 ab. Die interne UID 1000 wird daher extern auf 101000 abgebildet. Kennungen ohne nutzbare Zuordnung werden normalerweise als Überlauf-UID 65534 angezeigt.

Root innerhalb dieses Namensraums hat Capabilities für Ressourcen, die von ihm verwaltet werden, aber keine hostweiten Befugnisse. Das Laden eines Kernelmoduls oder Ändern der realen Systemuhr benötigt weiterhin Privilegien im ursprünglichen Benutzernamensraum. Eine UID-Zuordnung schützt nicht vor einem privilegierten Laufzeitumgebungs-Socket, der in den Container weitergereicht wird.

Eine private Sicht begrenzt auch nicht den Verbrauch. Ein Prozess mit eigenen PID- und Mount-Namensräumen kann weiterhin CPU und RAM verbrauchen. Cgroups begrenzen Mengen, während Capability-Begrenzungen und Seccomp Operationen einschränken.

Eine Kontrollgruppe oder Cgroup fasst Prozesse zusammen, um Ressourcenverbrauch zu erfassen und zu steuern. Namensräume bestimmen ihre Sicht; Cgroups regeln Mengen wie CPU-Zeit, Speicher und die Anzahl der Tasks. Kindprozesse erben die Gruppe ihres Elternprozesses, und die Hierarchie verhindert, dass eine Kindgruppe die Grenzen einer übergeordneten Gruppe umgeht.

Lies die Dateien von cgroup v2

Cgroup v2 nutzt eine einheitliche Hierarchie, normalerweise unter /sys/fs/cgroup. Eine Elterngruppe aktiviert Controller für ihre Kindgruppen über cgroup.subtree_control, zum Beispiel +cpu +memory +pids. Einzelne Dateien in jeder Kindgruppe enthalten Grenzen und Zähler.

Zu den Controllern gehören cpu, cpuset, memory, io, pids, hugetlb und rdma. Sie steuern CPU-Zeit, Platzierung auf CPUs und Speicherknoten, gewöhnlichen Speicher, Block-Ein-/Ausgabe, Taskanzahl, große Speicherseiten und RDMA-Ressourcen. Cgroup-bewusste Leistungsereignisse unterstützen Messungen, und cgroup.freeze pausiert die Ausführung einer Gruppe.

Unterscheide eine CPU-Obergrenze von einem Anteil

cpu.max enthält Kontingent und Periode in Mikrosekunden. 50000 100000 erlaubt 50 ms CPU-Ausführung pro 100 ms, entsprechend der Hälfte einer CPU. 200000 100000 erlaubt zwei CPUs entsprechende Laufzeit, die auf Kerne verteilt sein kann. max 100000 bedeutet keine Kontingentobergrenze. Sobald das Kontingent verbraucht ist, wartet die Gruppe auf die nächste Periode, selbst wenn eine CPU untätig ist.

cpu.weight legt bei Konkurrenz einen relativen Anteil von 1 bis 10.000 fest, mit dem Standardwert 100. Bei gleich platzierten, ausführbaren Gruppen auf vier CPUs teilen die Gewichte 100 und 300 die verfügbare Zeit im Verhältnis 1:3: ungefähr eine CPU und drei CPUs. Wird die höher gewichtete Gruppe untätig, kann die andere alle vier nutzen, sofern keine andere Grenze eingreift. Ein Gewicht ist weder eine Reservierung noch eine feste Obergrenze.

Begrenze die Ausschöpfung von Speicher und Tasks

memory.high erhöht oberhalb seines Schwellenwerts den Druck zur Speicherrückgewinnung und verlangsamt Tasks. memory.max setzt eine feste Grenze. Der Kernel versucht zunächst, Speicher zurückzugewinnen, indem er unter anderem Cache freigibt und verfügbare Auslagerung nutzt. Kann er nicht genug zurückgewinnen, beendet die OOM-Behandlung der Cgroup einen geeigneten Prozess innerhalb der betroffenen Gruppe.

Bei einem Wert von 512M für memory.max beträgt die Grenze 536.870.912 Byte oder 512 MiB. Ein Prozess mit Speicherleck kann Speicherrückgewinnung und schließlich eine OOM-Beendigung erzwingen. Das Opfer wird aber vom Kernel ausgewählt und muss nicht dieser Prozess sein. Die Gruppengrenze beschränkt das Ereignis auf die Gruppe, statt einen unbeteiligten Hostprozess auszuwählen.

pids.max zählt Prozesse und Threads. Bei einer Grenze von 100 schlägt weiteres Erzeugen mit EAGAIN fehl und begrenzt so das Taskwachstum einer Forkbombe. Eine Ein-/Ausgabegrenze wie 8:0 rbps=10485760 in io.max begrenzt Lesezugriffe auf das Blockgerät 8:0 auf 10 MiB/s.

Diese Dateien verbergen weder Hostprozesse noch Dateinamen. Außerdem können /proc/meminfo und Werkzeuge, die diese Datei lesen, den RAM des Hosts statt memory.max melden; die angezeigte Gesamtsumme allein beweist nicht, dass eine Cgroup keine Grenze hat. Ressourcenmessungen müssen auf der Ebene abgelesen werden, die die Grenze durchsetzt.

Eine zweckmäßige Containergrenze kombiniert Sichten, Ressourcensteuerung und eingeschränkte Befugnisse. Ein privater Dateibaum allein verhindert keine gefährlichen Systemaufrufe, und ein CPU-Kontingent verhindert keinen Zugriff auf eine freigegebene Hostdatei. Der Hostkernel setzt jede dieser Kontrollen durch.

Verringere die Befugnisse des Prozesses

Eine Laufzeitumgebung kombiniert Namensräume, Cgroups und ein Dateisystemimage mit Programmen und Bibliotheken. Sie kann die Grenze durch folgende Maßnahmen stärken:

• Die Arbeitslast ohne Root-Rechte ausführen oder Containerkennungen über einen Benutzernamensraum zuordnen.
• Linux-Capabilities abgeben, insbesondere weitreichende Befugnisse wie CAP_SYS_ADMIN und CAP_SYS_MODULE.
• Seccomp anwenden, um unnötige Aufrufe einzuschränken.
• SELinux- oder AppArmor-Regeln anwenden.
• Das Wurzeldateisystem schreibschützen, wo dies praktikabel ist.
• no_new_privs setzen, damit die Ausführung von Setuid-Programmen Privilegien nicht erhöhen kann.

Jede Kontrolle deckt einen anderen Weg ab. Ein schreibgeschütztes Wurzeldateisystem erlaubt weiterhin zulässige Netzwerkoperationen; ein Seccomp-Filter erlaubt weiterhin die Aufrufe auf seiner Liste. Der Entwurf sollte zu den Operationen passen, die die Anwendung tatsächlich benötigt.

Erkenne das Risiko des gemeinsam genutzten Kernels

Alle gewöhnlichen Container teilen sich den Hostkernel. Ein erreichbarer Kernelfehler kann daher den Host und andere Container kompromittieren. In einer VM verschafft die Ausnutzung des Gastkernels Kontrolle über dieses Gastbetriebssystem; um den Host zu erreichen, muss zusätzlich eine Grenze des Hypervisors oder der Geräte versagen.

Root innerhalb eines Containers ist besonders kritisch. Ohne Benutzernamensraum ist es für den Hostkernel UID 0, eingeschränkt durch Capabilities, Filter und systembestimmte Regeln. Der privilegierte Modus oder Zugriff auf das Wurzeldateisystem des Hosts kann diese Einschränkungen aufheben. Auch ein root gehörender Laufzeitumgebungs-Socket ist gefährlich: Sein Client kann die Laufzeitumgebung zu privilegierten Aktionen auffordern. Container-root auf eine unprivilegierte Hostkennung abzubilden macht diesen Socket weder sicher noch beseitigt es Kernelschwachstellen.

Wähle eine Grenze für die Arbeitslast

Ein Linux-Container benötigt einen Linux-Kernel. Plattformen auf Windows und macOS stellen daher häufig eine Linux-VM unter Linux-Containern bereit. VMs starten ein Betriebssystem und reservieren Speicher für jeden Kernel; Container starten gewöhnliche Prozesse und können Arbeitslasten dichter zusammenfassen.

Erkenne Zwischenformen

gVisor behandelt viele Container-Systemaufrufe in einem Kernel im Benutzeradressraum und verringert so den direkten Kontakt mit dem Hostkernel. Kata Containers gibt jeder Sandbox, häufig einem Kubernetes-Pod, eine schlanke VM; Container in dieser Sandbox teilen sich deren Gastkernel. Firecracker stellt MicroVMs mit einem minimalen Gerätemodell für Plattformen bereit, die Funktionen oder Containerarbeitslasten ausführen, darunter AWS Lambda.

Cloud-Systeme platzieren Container häufig innerhalb von VMs: Eine VM trennt Kunden, während Container die Anwendungen eines Kunden organisieren. Die Gastkernel und der Hostkernel bleiben getrennt. Ein Containerausbruch innerhalb einer VM belegt daher für sich genommen keinen Hypervisor-Ausbruch.