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

[Hagen (Gast)]

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

[Wilhelm M. (wimalopaan)]

Wie kann er denn aus dem LXC "ausbrechen"? Kannst Du das Szenario 
beschreiben?

[Peter II (Gast)]

ich denke dafür sind Ansätze wie SELinux oder AppArmor besser geeignet. 
Da darf auch root nicht mehr alles.

[Hagen (Gast)]

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

[Wilhelm M. (wimalopaan)]

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.

[S. R. (svenska)]

Hagen schrieb:
> Natürlich nicht im Detail, aber was ist dort
> der grundsätzliche Ansatz?

Good / Best Practises.

[Noch einer (Gast)]

> 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.

[foobar (Gast)]

Linux Capabilities

[Lukey S. (lukey3332)]

firejail für Einzelne Programme

[(prx) A. K. (prx)]

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.

[Wilhelm M. (wimalopaan)]

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.

[S. R. (svenska)]

Ja, aber Hagen-Personaler ist nicht an geringerer Wahrscheinlichkeit 
interessiert, sondern nur an vollkommener Sicherheit.

[Johann L. (radiostar)]

S. R. schrieb:
> Ja, aber Hagen-Personaler ist nicht an geringerer
> Wahrscheinlichkeit
> interessiert, sondern nur an vollkommener Sicherheit.

vollkommen sicher ist nur Eines - und selbst da sind einige Religionen 
anderer Meinung.