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

Gast #4811107
Lesenswert?
• ▲
▼
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
Lesenswert?
• ▲
▼
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
Lesenswert?
• ▲
▼
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
Lesenswert?
• ▲
▼
> 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
Lesenswert?
• ▲
▼
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
Lesenswert?
• ▲
▼
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

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren