it-swarm-eu.dev

Geheimnisse vor Root unter Linux bewahren

Ich suche nach Möglichkeiten, ein Linux-System zu härten, damit selbst bei vollem Root-Zugriff (durch legitime oder nicht legitime Mittel) einige Geheimnisse nicht zugänglich sind. Aber zuerst ein kleiner Hintergrund.

Viele der verschiedenen Linux-Sicherheitsmodelle (SELinux, TOMOYO usw.) konzentrieren sich darauf, die Möglichkeiten von Prozessen durch Richtlinien einzuschränken und sicherzustellen, dass sie keinen vollständigen Root-Zugriff benötigen. Sie zielen darauf ab, Exploits in sich zu behalten, damit andere Teile des Systems nicht beeinträchtigt werden können. Es scheint jedoch, dass diese nicht direkt den Fall angehen, in dem bereits die vollständige Wurzel gewonnen wurde - oder sogar Geheimnisse vor dem gültigen Wurzelbenutzer bewahren. Es scheint, dass diese normalerweise zur Laufzeit nur von der realen Wurzel ausgeschaltet werden können.

Ein anderer Ansatz besteht darin, die Möglichkeiten zu beschränken, uneingeschränktes Root-Verzeichnis zu erhalten. Beispielsweise wird nicht der gesamte Zugriff auf einen remote verbundenen Root-Benutzer zugelassen, sondern es ist eine Anmeldung über die physische Konsole erforderlich. Dies ist jedoch auch nicht mein Ziel - die Annahme ist, dass solche Schutzmaßnahmen bereits überwunden wurden und die Wurzel so legitim wie möglich ist.

Es ist offensichtlich, dass jeder mit physischem Zugriff auf die Maschine alles auf der Festplatte und möglicherweise auch alles im Speicher speichern kann. Es ist auch offensichtlich, dass nach dem Neustart keine Sicherheitsversprechen abgegeben werden können, wenn der Root-Benutzer die Möglichkeit hat, Binärdateien oder Kernel-Images zu ändern. Ich interessiere mich nur für Angriffe, die ohne Neustart des Systems durchgeführt werden können.

Während des Startvorgangs werden Geheimnisse höchstwahrscheinlich an vielen Orten übertragen, und es werden viele sicherheitskritische Funktionen benötigt. Es ist natürlich großartig, wenn Geheimnisse auch während des Startvorgangs geschützt werden können, aber was für mich ausreicht, ist ein Schritt während des Startvorgangs, bei dem erhöhte Berechtigungen gelöscht werden können und nach dem es keine Möglichkeit gibt, sie wiederzugewinnen.

Wie kann man unter diesen Einschränkungen unter Linux verhindern, dass der vollständige Root-Benutzer auf einige Geheimnisse zugreift?

  • Kann es Dateien im Dateisystem geben, auf die nicht einmal das gesamte Stammverzeichnis zugreifen kann, sondern auf einige Prozesse? Einige aktuell ausgeführte Prozesse oder sogar neue Prozesse, die von den Prozessen gestartet wurden, auf die derzeit Zugriff besteht?

  • Können Geheimnisse durch Ausführen von Prozessen im Speicher gehalten werden, sodass selbst die vollständige Wurzel auf keinen Fall darauf zugreifen kann? Können diese Geheimnisse auf irgendeine Weise auf neue Prozesse übertragen werden, die die Wurzel nicht beeinflussen kann?

Diese Frage ist schwer zu schreiben, damit ich für mich relevante Antworten bekomme. Daher werde ich versuchen, die Frage bei Bedarf genauer zu bearbeiten.


Offensichtliche Dinge, die in den Sinn kommen und begrenzt werden müssen, sind:

  • Deaktivieren Sie den Zugriff auf/proc/mem

  • Deaktivieren Sie den Zugriff auf/proc/<pid>/mem

  • Deaktivieren Sie den Zugriff auf/proc/<pid>/fd/*

  • Deaktivieren Sie das Laden von Modulen (vorzugsweise erst, nachdem einige Module geladen wurden)

  • Deaktivieren Sie den ptrace-Zugriff auf einen beliebigen Prozess

56
Nakedible

Tatsächlich ist es möglich, root if einzuschränken. Man ist bereit, eine solche Einschränkung als grundsätzlich dem Betriebssystem vertrauen zu definieren. Dies kann mit SELinux (das ich kenne) und vermutlich anderen solchen Systemen erfolgen. Das beste Beispiel für SELinux, das ich so gesehen habe, ist Russell Cokers SELinux Machine spielen .

Als kurze Übersicht über die Funktionsweise ist der Name "root" in Unix nichts Besonderes. Die UID 0 ist. UID 0 bedeutet "Vertraue allem, was ich sage". Dies gilt speziell für das Standardzugriffsmodell, das unter Unices, Unixen oder wie auch immer Sie "Unix" pluralisieren.

Mit LSM oder Linux-Sicherheitsmodulen können Sie sich in nahezu alles einbinden und Aktionen nach Belieben prüfen/ablehnen. Im Fall von SELinux werden SELinux-Berechtigungen nach Unix-Berechtigungen überprüft, sodass Ihr Ablauf folgendermaßen aussieht:

Event ----> Has Unix Permissions? ---> Has SELinux Permissions? ---> Let it happen

Der nächste zu verstehende Schritt ist, dass es verschiedene Versionen der SELinux-Richtlinie gibt oder gab. Bevor ich darauf eingehe, verstehe ich das in SELinux:

  • inodes haben Typen mit dem Suffix _t, die auch als Domänen bezeichnet werden können. und
  • benutzer haben Rollen mit dem Suffix _r.

Zusammen steuern sie, welche Aktion ein Benutzer in einer bestimmten Rolle ausführen darf und was ein Prozess in einer bestimmten Domäne ausführen darf.

Jetzt gibt es drei wichtige SELinux-Richtlinien:

  1. gezielt. Dies ist die Standardrichtlinie für Desktops wie Fedora. Die Idee von Targeting ist, dass kritische Systemdienste und Daemons in Domänen ausgeführt werden, aber vieles, was Sie als Endbenutzer tun, wird in unconfined_u:unconfined_r:unconfined_t Ausgeführt. Keine Preise für das Erraten, was das bedeutet - wenn Unix-Berechtigungen funktionieren, wird SELinux effektiv weitergeleitet.
  2. streng. Diese Richtlinie beinhaltet das vollständige Entfernen von unconfined_u. Dies ist kein einfacher Vorgang, insbesondere auf dem Linux-Desktop (d. H. init 5). Insbesondere das X11-Sicherheitsmodell ist nicht besonders gut und erfordert für einige Anwendungen häufig unconfined_t. Sie können dies tun , aber ich würde erwarten, dass die Arbeit mit X11 schwieriger (wenn auch nicht unmöglich) ist, insbesondere wenn Sie GUI-Anwendungen ausführen, für die root erforderlich ist. Derzeit läuft ein Projekt zur Unterstützung von SELinux-ähnlichen Funktionen in X mit dem Namen XACE (X Access Control Extensions) .
  3. MLS. MLS steht für mehrstufige Sicherheit und bedeutet das Ende der Berechtigungszeichenfolge: user_u:system_r:httpd_content_t.s0-s2:c5-c7, Dh diese s und c Zahlen bedeuten tatsächlich etwas. Insbesondere bilden sie ein kein Auflesen, kein Aufschreiben Setup, so dass die Informationen, die sie sehen können, begrenzt sind, wenn der Prozess nicht auf einer bestimmten Ebene ausgeführt wird. Die Idee dieser Informationsebene ist der Schutz klassifizierter Vermögenswerte - SELinux wurde ursprünglich von der NSA entwickelt, vermutlich zu diesem Zweck.

Das ist also dein Hintergrund. Nun, laut den Webseiten (siehe FAQ ) root ist UID 0 auf dem Spielautomaten; root wird jedoch so eingestellt, dass es als user_r und nicht als sysadm_r im strict Politik. Dies bedeutet, dass der Benutzer keine Verwaltungsfunktionen über die Shell ausführen darf.

Es wäre also interessant zu wissen, welchen Status die anderen Prozesse haben, für die root erforderlich ist. Vermutlich wurden solche Prozesse entsprechend gekennzeichnet und verfügen über Richtlinien, die ihnen den erforderlichen Zugriff ermöglichen. Die Frage lautet dann, wie Sie das System verwalten und ob einer dieser Prozesse eine Shell im Kontext dieses Benutzers starten kann. In diesem Fall können Sie dennoch einen Exploit verwalten.

Da der Spielautomat derzeit nicht verfügbar ist (zum Zeitpunkt des Schreibens), arbeite ich hier an Annahmen. Im Wesentlichen benötigen Sie jedoch einen Prozess, der in sysadm_r und mit UID 0 als Ziel für einen Exploit ausgeführt wird. Angenommen, ein solcher Prozess existiert und ist ausnutzbar, könnten Sie immer noch zu root gelangen. Ich kann mir zwei Optionen vorstellen, um weiterhin über root verwalten zu können:

  • Entweder gibt es einen vertrauenswürdigen Übergang, der bedeutet, dass root dann zu sysadm_r (Weniger sicher) oder übergehen kann
  • Auf verschiedenen Runlevels gilt eine andere Richtlinie. Um den Computer zu verwalten, setzt man den Runlevel auf 1 und die Richtlinie schränkt root nicht ein. Ich vermute hier.

Zusammenfassung

Wenn Ihre Frage lautet: "Kann ich das jetzt einfach und sicher tun?" Die Antwort ist nein. Wenn Ihre Frage lautet: "Ich bin bereit, etwas über SELinux zu lernen, mich mit meiner Distribution zu beschmutzen und eine Menge Dinge zu ertragen, die nicht funktionieren", ist die Antwort, dass es möglich ist, root viel mehr als Ihre durchschnittliche Installation einzuschränken. Dies macht Sie jedoch in keiner Weise für Exploits unverwundbar - es macht es einem Benutzer nicht unmöglich, diese zusätzliche Zugriffskontrolle entweder in Software oder physisch zu umgehen.

Also ja, Sie können Dinge für root unsichtbar machen; Abgesehen von der zusätzlichen technischen Belastung gelten jedoch dieselben Einschränkungen wie bei jeder Einrichtung der Zugriffskontrolle für normale Benutzer - es gibt keine Silberkugel.

Oh und eklatante Eigenwerbung: Vielleicht gefällt dir mein Blog-Beitrag über Geheimnisse in Software speichern . Es ist auf dem Security Stackexchange-Blog, daher fühle ich mich nicht so schlecht, wenn ich dafür werbe. Wie Sie sehen, gibt es im Wesentlichen Mechanismen, die einem Angreifer (und Ihnen) das Leben erheblich erschweren, aber am Ende handelt es sich um "Schildkröten ganz nach unten", d. H. Grundsätzlich unmöglich.

33
user2213

Ich musste dieses Problem schon einmal angehen, als ich von einem Kunden angesprochen wurde, der "private Nachrichten" zwischen Benutzern auf einer Website schützen wollte. Unter bestimmten Umständen ist es möglich, einige Daten zu schützen, dies ist jedoch relativ begrenzt.

Mein Ansatz war es, einfach eine verschlüsselte Version der Notiz auf dem Server zu speichern und an sie zu senden (natürlich einmal authentifiziert) und sie dann vollständig clientseitig zu entschlüsseln. Dies bedeutet, dass die Notizen auch im Falle einer vollständigen Beeinträchtigung der Serversicherheit (d. H. Root-Zugriff) sicher blieben. Die Einschränkungen hiervon jedoch:

  • Geschützte Daten sind nur bis zum Zeitpunkt des Kompromisses und nicht später sicher. Abhängig von der zum Verschlüsseln der Informationen verwendeten Methode kann ein verwurzelter Server den Benutzer dazu verleiten, die Entschlüsselungsschlüssel (JavaScript-Injection oder für native GUI-Clients ein kompromittiertes Client-Update auszugeben) oder die Entschlüsselungsschlüssel auf andere Weise abzufangen (sofern die Schlüssel basieren) Mit derselben Methode wie der Authentifizierung des Benutzers, z. B. einem Kennwort, können sie während des serverseitigen Authentifizierungsprozesses abgefangen werden.
  • Die Übertragung erfordert eine perfekte Geheimhaltung der Weiterleitung, da sonst die verschlüsselten Daten abgefangen, gespeichert und dann nach dem Kompromiss entschlüsselt werden können, wie oben erläutert.
  • Dies schützt nichts, wenn der Client ebenfalls gefährdet ist. Wenn Sie verschlüsselte Daten nicht vollständig in Ihrem eigenen Kopf verarbeiten (und wenn Sie können, verdienen Sie eine Trophäe oder etwas anderes), geben Sie vertrauliche Daten an etwas weiter, und nichts ist - perfekt kompromisslos.
  • Es gibt keine Möglichkeit, diese Datenserver-Seite zu verwenden (d. H. Zu Indizierungszwecken), es sei denn, entschlüsselbare/Klartext-Metadaten werden daneben gespeichert, wodurch möglicherweise zusätzliche Informationen angezeigt werden.

Dies schränkt im Wesentlichen die potenziellen Verwendungsmöglichkeiten für dieses Szenario ein, und es gibt immer noch Schwachstellen, aber es ist möglich, dass es in einigen Situationen funktioniert. Passwort-Hashing ist ein (einigermaßen) erfolgreiches Beispiel für den Schutz vor Root-Kompromissen, da selbst beim physischen Zugriff die Passwörter eines Benutzers nicht angezeigt werden (außer natürlich, wenn dieses Passwort nach dem Kompromiss übertragen wird).

Es gibt andere Beispiele in diesem Thread, die ebenfalls untersucht werden sollten. Denken Sie jedoch über das clientseitige Verarbeitungsszenario nach, indem Sie den Server einfach als sicheren Speicherdienst verwenden.

TC

14
TC Fox

Kann es Dateien im Dateisystem geben, auf die nicht einmal das gesamte Stammverzeichnis zugreifen kann, sondern auf einige Prozesse? Einige aktuell ausgeführte Prozesse oder sogar neue Prozesse, die von den Prozessen gestartet wurden, auf die derzeit Zugriff besteht?

Nein. Wenn ein Prozess auf sie zugreifen kann, kann auch root darauf zugreifen. Wenn Sie solche Dinge tun möchten, müssen Sie das gesamte System stark modifizieren, möglicherweise ein System, das einen unveränderlichen Kernel von einem schreibgeschützten Gerät startet und das Root bestimmte Datei-/Speicherzugriffe verweigert, während es anderen Benutzern erlaubt, die root können. ' t verkörpern.

Können Geheimnisse durch Ausführen von Prozessen im Speicher gehalten werden, sodass selbst die vollständige Wurzel auf keinen Fall darauf zugreifen kann? Können diese Geheimnisse auf irgendeine Weise auf neue Prozesse übertragen werden, die die Wurzel nicht beeinflussen kann?

Siehe Antwort oben.

Sie können den Zugriff für root per Definition nicht einschränken. Wenn Sie den Root-Zugriff einschränken, ist es kein Root-Benutzer mehr.

Wenn ich den Root-Zugriff auf Geheimnisse verweigern wollte, würde ich versuchen, sie zu verbergen. Kryptografische Container, die möglicherweise im Swap-Speicher oder an einem anderen Ort versteckt sind und nur mit einem Kennwort oder einer anderen Art von Steganografie zugänglich sind. Es ist verdammt schwer, eine Nadel im Heuhaufen zu finden, obwohl dies nicht unmöglich ist.

6
Falcon

Es gibt eine Reihe indirekter Möglichkeiten, wie root beliebigen Code ausführen kann. Sie können sie deaktivieren, und einige Sicherheits-Frameworks deaktivieren sie möglicherweise, aber sie beeinträchtigen die Fähigkeit von root, Verwaltungsaufgaben auszuführen.

Beispielsweise kann root direkt auf Festplatten lesen und schreiben, wobei alle Arten von Dateisystemberechtigungen umgangen werden. Sie können diese Funktion entfernen, aber root kann im Notfall kein vollständiges Dateisystem auf eine neue Festplatte verschieben.

Root kann Kernelmodule laden und damit alles tun, was der Kernel kann. Sie können diese Funktion entfernen, aber dann das Laden von Treibern für Hot-Plug-fähige Medien ausschließen. (Dies kann in 0,001% der Unix-Installationen wünschenswert sein, ist jedoch nicht der allgemeine Fall.)

Root kann ausführbare Dateien aktualisieren, mit denen sich Benutzer anmelden können, z. B. login oder sshd. Diese Daemons verwalten die Benutzerauthentifizierung. Wenn Sie also ihren Code steuern, können Sie eine Hintertür einfügen. Sie können diese Fähigkeit entfernen, aber dann kann root keine Sicherheitsupgrades durchführen.

Root kann Benutzer erstellen und entfernen sowie Authentifizierungsdaten ändern: Wenn Sie /etc/passwd Bearbeiten können, um ein Konto hinzuzufügen, können Sie es auch bearbeiten, um ein Konto vorübergehend kennwortlos zu machen. Sie können diese Funktion entfernen, indem Sie einige Dateien auch für root schreibgeschützt machen. Am Ende erhalten Sie jedoch ein System, auf dem Sie keine Benutzerkonten erstellen oder entfernen können, ohne einen Neustart durchzuführen.

Sicherheits-Frameworks erstellen effektiv Benutzer mit eingeschränktem Root-Status, die nur in einer Teilmenge des Systems root sind - root nur in einer virtuellen Maschine, nicht im „realen“ System. Diese eingeschränkte Wurzel verliert die Möglichkeit, Verwaltungsaufgaben auf dem realen System auszuführen. Ich denke, Virtualisierung ist das, wonach Sie suchen.

Dies ist relativ einfach zu erreichen, wenn ein Selinux-System mit zwei Schlüsseln verwendet wird: root hat keine Berechtigungen, etwas zu tun, und ein anderer Benutzer ohne Root-Berechtigungen tut. Um also etwas zu ändern, müssen Sie zuerst der sein Nicht-Root anderer Benutzer, dann "su" Sie zu root, um die Änderung vorzunehmen.

Keiner der isolierten Benutzer kann etwas tun oder sehen.

Ich benutze das. Es funktioniert wirklich gut.

3
cnd

Der tatsächliche Bedarf ist in der Frage nicht genau definiert, aber zwei mögliche Lösungen, auf die angedeutet wird, wurden nicht erwähnt:

  • Behälter
  • HSMs

Container - die natürlich nur eine architektonisch sinnvollere Herangehensweise an das sind, was Stück für Stück mit Werkzeugen wie Jails und SELinux gemacht wurde - können im Zusammenhang mit einer Neuformulierung der Frage von Bedeutung sein - gibt es eine Möglichkeit, dass eine Unix-ähnliche Logik Das System kann Angreifern ausgesetzt sein, so dass es möglicherweise vom Root gefährdet ist, die Geheimnisse des physischen Systems jedoch weiterhin geschützt sind. Mit Containern nähern wir uns diesem Ziel. Ein kürzlich veröffentlichtes Papier der Sicherheitsgruppe NCC ist eine Lektüre wert: https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf

HSMs sind Hardware-Verschlüsselungsgeräte, die das Abrufen von Entschlüsselungsschlüsseln über physische oder logische Methoden verhindern. Dies kann eine Antwort auf die Frage sein, die neu formuliert wurde: Ich habe Geheimnisse, die ich sicher entschlüsseln muss. Was mache ich mit den Schlüsseln?.

2
Jonah Benton

Wie Falcon sagte, hat der Root-Benutzer per Definition Zugriff auf all diese Dinge, oder er ist nicht länger der Root-Benutzer.

Der Kernel steuert die gesamte Hardware. Sobald Sie Root sind, haben Sie denselben Zugriff. Sie benötigen wirklich Virtualisierung, damit Ihr Root-Benutzer nur Root für das virtualisierte Betriebssystem ist, auf dem er ausgeführt wird, und einige Hypervisor-Dateien außerhalb davon root. (um nicht zu sagen, dass Hypervisoren nicht ausnutzbar sind, aber was Sie versuchen, ist gleichbedeutend damit).

2
Bradley Kreider

Haben Sie Grsecurity ausprobiert? Es kann Root-Benutzer auf jede mögliche Weise effektiv einschränken. https://grsecurity.net/

Grsecurity in Verbindung mit PaX macht Ihre Box zu einer uneinnehmbaren Festung ... wenn Sie es richtig machen

2
Jauzsika