reagieren, wenn ein Prozess root-Rechte erlangt (Linux)

Gast #4811107
Hallo,
bei der Entwicklung einer Web-Anwendung mit integrierter Skriptsprache 
können wir nicht ausschließen, dass der Benutzer beliebigen, auch 
bösartigen, Code ausführt. Daher lassen wir die Anwendung in einer 
virtuellen Maschine (z.Zt. LXC) laufen. Doch auch dies ist nicht sicher, 
wenn es dem Benutzer gelingt, root-Rechte zu erlangen, da er dann die 
virtuelle Maschine verlassen und den Hostrechner "übernehmen" kann.

Nun ist unser Gedanke, alle Systemaufrufe (setuid, setgid, ...) 
abzufangen, die es ermöglichen, root-Rechte zu erlangen und die 
virtuelle Maschine abzuschalten, falls der setuid-Aufruf von einem nicht 
vorher authorisierten Prozess stammt. Gibt es Ansätze in dieser 
Richtung?
Es ist ja nicht ganz trivial. Erstens ist die Frage, welche 
Systemaufrufe genau abgefangen werden müssen? Gibt es außer setuid, 
setgid weitere Möglichkeiten, evtl. auch unter Umgehung der 
dokumentieren Systembibliotheken, root-Rechte zu erlangen? Zweitens 
benötigen bestimmte Prozesse weiterhin die Möglichkeit, als root zu 
laufen, um ihre Aufgaben erfüllen zu können. Wie kann man diese sinnvoll 
von unerlaubten Prozessen unterscheiden?

Dann interessiert uns noch die Frage, wie große Cloudanbieter (Azure, 
AWS usw.) sicherstellen, dass ihre Systeme sicher sein sollen, da 
offenbar keine Virtualisierung gegen einen Ausbruch von Gastsystem ins 
Hostsystem geschützt ist. Natürlich nicht im Detail, aber was ist dort 
der grundsätzliche Ansatz?

Danke
Hagen
Gast #4811130
Wilhelm M. schrieb:
> Wie kann er denn aus dem LXC "ausbrechen"? Kannst Du das Szenario
> beschreiben?

Ich habe noch nicht versucht, es im Detail zu verstehen geschweige denn 
auszuprobieren. Doch wenn du nach "lxc ausbrechen" oder "lxc exploit" 
googlest, findest du etliche Möglichkeiten, z.B.:
http://experiment4.de/container-exploit-shocker-kann-aus-lxcdocker-ausbrechen/ 
(Dieser ist zwar inzwischen gefixt, doch es wird neue Lücken geben.)

Danke
Hagen
#4811137
Ok, das bezieht sich auf ein altes LXC, aktuell ist 2.0.6

LXC ist eine Kombination von kernel namespaces und Apparmor und SELinux.

Viele Hoster machen das, oder OpenVZ oder VServer oder ...

Wem das Prinzip mit einem(!) Kernel noch zu unsicher ist, der muss dann 
statt Paravirtualisierung eine volle Virtualisierung via VirtualBox, 
qemu, o.ä. herstellen.
Gast #4812794
> aber was ist dort der grundsätzliche Ansatz?

Die bezahlen in ihren Bug Bounty Programmen für neu gefundene Bugs. 
Fixen ihre VM, bevor jemand anderes einen Exploit schreiben kann. 
Behaupten die zumindest.
#4813696
Wilhelm M. schrieb:
> Wem das Prinzip mit einem(!) Kernel noch zu unsicher ist, der muss dann
> statt Paravirtualisierung eine volle Virtualisierung via VirtualBox,
> qemu, o.ä. herstellen.

Auch volle Virtualisierung wie VMware kann nicht als absolut sicher 
angesehen werden. Da gab es auch schon Bugs. Aber um vor elektronischem 
Einbruch vollständig sicher zu sein, muss man die Daten in Karteikarten 
aus Pappe speichern und per Briefpapier kommunizieren.
#4813699
A. K. schrieb:
> Wilhelm M. schrieb:
>> Wem das Prinzip mit einem(!) Kernel noch zu unsicher ist, der muss dann
>> statt Paravirtualisierung eine volle Virtualisierung via VirtualBox,
>> qemu, o.ä. herstellen.
>
> Auch volle Virtualisierung wie VMware kann nicht als absolut sicher
> angesehen werden. Da gab es auch schon Bugs. Aber um vor elektronischem
> Einbruch vollständig sicher zu sein, muss man die Daten in Karteikarten
> aus Pappe speichern und per Briefpapier kommunizieren.

Ja klar, wo SW ist, sind auch Fehler. Allerdings sind die Möglichkeiten 
für das Ausnutzen von Schwachstellen bei voller Virtualisierung (mit HW 
Unterstützung durch Privilegien-Ringe) geringer als bei 
Para-Virtualisierung.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 9 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.