Ich muss ein Horrorszenario umsetzen...

[ady1980]

Hallo,
also wie im Titel schon steht, habe ich die Aufgabe in etwa 3-4 Monaten ein echtes Horrorszenario umzusetzen. Es ist zwar noch ne weile hin, aber Gedanken sollte ich mir schon jetzt machen.

Geht um folgendes:

Auf einem Server (der vermutlich in der ersten Phase gleichzeitig als Webserver dient) sollen ssh-zugänge für kunden eingelegt werden.
geschätzte 1000 Stück für jeweils 24 Stunden, also immer fliegender Wechsel.

Die Kunden sollen also nach dem Login Ihre eigene Umgebung betreten und in dieser Umgebung benötigen die Kunden root-rechte (nein, das ist kein witz).

So jetzt frage ich mich, wie gehe ich hier am besten vor.

chroot ist gut, aber nicht gut genug.
eventuell wollte ich auch in den agb's verankern, das die chroot in einem Screen erfolgt und wir uns als betreiber vorbehalten stichprobenartig in so eine session reinzuschalten.

Desweiteren muss ich mich auch vor einem problem schützen:
Den Usern stehen aus technischen gründen Tools wie nmap und konsorten zur verfügung, sprich wir müssen uns gegen Mißbrauch schützen.

Hier habe ich eventuell daran gedacht, den Inetverkehr zu unterbinden, da die Kunden aber auch daten aus dem Netz dort raufbugsieren sollen bin ich mir da nicht ganz sicher.

Tja, ihr seht das ist ziemlich Komplex.

Vielleicht habt Ihr Ideen oder Anregungen für mich, würde mich freuen!


MfG,
ady1980

[timeless2]

Kannst du die Hintergründe etwas näher erläutern, denn so wirkt das eigenartig und wir können dir dann auch besser helfen.

[ady1980]

Das ganze sieht etwa so aus:

- Es wird ein user angelegt (user1)
- Im /home von user1 wird chroot-verzeichnis angelegt
- Dieses wird mit einem kompletten Linuxsystem befüllt
- Der User kann dann an diesem System herumkonfigurieren, Programme installieren, etc...
- Das Ergebnis wird dann von uns weiterverarbeitet.


Mehr zum Thema wozu machen wir das, darf ich leider nicht verraten :-(

[duergner]

Wofür brauchen die da root Rechte? Ich sehe den Hintergrund nicht ganz. Außer du willst virtuelle Rechner laufen lassen aber dann haben sie die root Rechte ja auf den virtuellen Maschinen. In ihrem chroot brauchen sie doch keine root Rechte. Einfach alle Dateien die in einem Standard System root gehören einem dedizierten Benutzer geben und diesen Benutzer in alles Gruppen des virtuellen Systems stecken und gut ist. Wenn du das System danach wieder weiterverarbeitest, musst du nur das Ownership wieder entsprechend ändern. Das hat auch gleich den Vorteil, dass sie z.B. keine Dienste an priviligierte Ports binden können, etc.

Wenn das nicht geht, dann musst du halt nochmal genauer erklären, wieso das nicht geht.

[EDIT]
Achja aber 1000 chroot mit einem kompletten Linux System wird schon rein vom Speicherplatz ger eng auf einer Maschine IMHO.

[ady1980]

hi,
nun die user haben die möglichkeit in diesem system Programme nachzuinstallieren, diese werden dann logischerweise vermutlich mit der uid 0 angelegt.

ansonsten ist die idee, die ownership zu ändern schonmal nen guter ansatz!

[Joe User]

Ich würde dafür UML oder QEMU und aus Platzgründen ein Embeddedsystem als "Gastsystem" verwenden.

[duergner]

Ne das wird dann nicht funktionieren, wenn die Nutzer dafür auf die Platform Tools wie apt, YaST oder auch nur dpkg oder rpm zurückgreifen sollen.

Aber ich denke es wäre durchaus sinnvoll, noch ein paar weitere Infos rauszurücken. So wie ich das sehe soll das irgendetwas in der Richtung sein, dass ein Kunde einen Server/Rechner konfigurieren kann, den ihr danach auf eine reelle Maschine packt, oder? Da wäre es vielleicht einfacher, ein High-Level Tool zu schreiben, dass nur die Konfiguration und die Auswahl der Packete/Dienste machen lässt und welche ihr danach entsprechend in ein reelles System übersetzt. Aber vielleicht irre ich ja auch komplett was den Verwendungszweck angeht.

[duergner]

Ich würde dafür UML oder QEMU und aus Platzgründen ein Embeddedsystem als "Gastsystem" verwenden.

1000 UML Instanzen auf einer Maschine? Das halte ich für absolut nicht machbar. Ich glaube nicht, dass man UML so skalieren kann.

[ady1980]

Nun, ein HighLevel Tool wird es auch geben in gewisserweise.

Dieser Zugang soll für Kunden sein, die wirklich kontrolle haben wollen über Ihre Umgebung.

Im prinzip sollen, die User sich bewegen können, wie als wenn Sie z.B. Gentoo in einer chroot bauen.

Das System mit UML bin ich mir nicht sicher, denn wir haben ja nur eine IP-Adresse.
Dann müssten wir ja auch entsprechend 1000 ssh-daemons an unterschielichen Ports am laufen haben bzw. auf jeder Maschine einen, aber das routen in iptables ist unpraktikabel.
Oder hab ich hier falschen Denkansatz?

[alexander newald]

Für jeden Benutzer einen normalen Account anlegen. Keine Root Rechte vergeben! Eine Chrootumgebung für den Benutzer erstellen und alle Dateien auf diesen Benuter setzen.

Beispiel

Code: Select all

useradd test001 && mkdir /home/test001
create_chroot /home/test001
chown test001.users /home/test001
mount /proc /home/test001/proc

einloggen lassen

umount /home/test001/proc
rm -r /home/test001
userdel test001

Einige Dinge werden evtl. nicht funktionieren (z.B. das Mounten von Loop Devices ins Dateisystem) aber das muss ja auch nicht unbedingt.

[ady1980]

Für jeden Benutzer einen normalen Account anlegen. Keine Root Rechte vergeben! Eine Chrootumgebung für den Benutzer erstellen und alle Dateien auf diesen Benuter setzen.

Beispiel

Code: Select all

useradd test001 && mkdir /home/test001
create_chroot /home/test001
chown test001.users /home/test001
mount /proc /home/test001/proc

einloggen lassen

umount /home/test001/proc
rm -r /home/test001
userdel test001

Einige Dinge werden evtl. nicht funktionieren (z.B. das Mounten von Loop Devices ins Dateisystem) aber das muss ja auch nicht unbedingt.

Ja, das als solches klingt ganz gut, nur werden die User eigene Programme mithilfe des jeweiligen Paketsystems der Distri installieren, dieser werden dann inho auch mit root-rechten versehen, so es für configs, etc... denn nötig ist.

Deshlab ist diese Vorschlag eher ungeeignet für dieses Szenario.

[Joe User]

Wenn die User root-Rechte bekommen sollen, musst Du für jeden User ein virtuelles System bereitstellen. Jedes dieser virtuellen Systeme benötigt eine Mindestmenge an Festplattenplatz und RAM. Wenn wir mal 100MB HDD und 8MB RAM pro virtuellem (Embedded-)System veranschlagen, macht das bei 1000 Usern: 100GB HDD und 8GB RAM. Das ist noch problemlos machbar, spätestens beim doppelten RAM-Bedarf der User ist mit "normaler PC-Hardware" Feierabend. Wenn Dir keine entsprechende Hardware zur Verfügung steht, ist das Projekt gestorben...

Zum Thema IP-Adressen: Da Du lediglich SSH anbieten willst, kannst Du das Host-System als SSH-Consolen-Server nutzen und leitest die Verbindungen an die virtuellen Systeme (10.0.0.0/8) weiter.

[ady1980]

Joa das wir fette Hardware hinstellen müssen haben wir schon Zähneknirschend festgestellt.

Wenn man das ganze noch auf RAID und auf eine redundanz der Maschine selbst ummünzt...

Achja, wir brauchen nicht 100MB pro User, wir brauchen geschätzt 1,4 GB pro Kopf *g*

[-ec-]

was soll das denn bitte alles sein, wenn du 1,4 gb pro user brauchst?
ansonsten ist das doch simpel:

1000 * 1,4gb = 1400gb = 1,4tb

musst dir halt nen paar platten mehr kaufen 8)

[alexander newald]

Ja, das als solches klingt ganz gut, nur werden die User eigene Programme mithilfe des jeweiligen Paketsystems der Distri installieren, dieser werden dann inho auch mit root-rechten versehen, so es für configs, etc... denn nötig ist.

Deshlab ist diese Vorschlag eher ungeeignet für dieses Szenario.

Nein, da ja alle Dateien die Rechte des eingeloggten Benutzers haben, sind keine Root Rechte nötig (Und sollten es auch nicht sein, denn hat man ein Programm mit root Rechten und kann das als root ausführen, kommt man auch aus der chroot Umgebung raus...)

Probiers doch einfach mal aus:

Kleines SuSE (von mir aus) System installieren, mkdir /chroot/user0001

cp -a /usr /sbin ... /chroot/user0001 (Für ... alles ausser /proc und /chroot angeben)

mkdir /chroot/user0001/proc

chown user0001.users /chroot/user0001 -R
mount /proc -t proc /chroot/user0001/proc

su - chroot0001
chroot /chroot/user0001

Irgendwie so in der Richtung...

[alexander newald]

Ach ja, man sollte noch /etc/passwd, /etc/shadow und /etc/fstab anpassen und dort zumindest den user root und die Partitionen komplett rausnehmen.

[ady1980]

Probiers doch einfach mal aus:

Kleines SuSE (von mir aus) System installieren, mkdir /chroot/user0001

cp -a /usr /sbin ... /chroot/user0001 (Für ... alles ausser /proc und /chroot angeben)

mkdir /chroot/user0001/proc

chown user0001.users /chroot/user0001 -R
mount /proc -t proc /chroot/user0001/proc

su - chroot0001
chroot /chroot/user0001

Irgendwie so in der Richtung...

Hmmmm, ja aber wenn ich das nun so mache und bin dann in meiner "entrooteten" umgebung und mache meinetwegen apt-get install apache2
dann wird es programme geben, wo apt dann root-rechte über die daten bügelt, was dann bedeuten müsste, das der kune diese nicht mehr modifizieren kann.

oder irre ich mich da?

[alexander newald]

ich würde jetzt sagen nein, da der normale Benutzer ja keine root Rechte vergeben kann. Das musste aber wohl einmal ausprobieren.

[duergner]

Ich wäre etwas skeptisch, dass apt/dpkg so einfach und sauber als nicht-root läuft. apt-get versucht ja z.T. auch Dienste neu zu starten und das wird auf jeden Fall fehlschlagen, wenn der Nutzer keine root-Rechte hat. Also ich bin etwas sehr skeptisch was dieses Szenario angeht, aber man kann es ja mal testen.

[alexander newald]

Dienste neu starten bringt sowieso nichts, denn wenn einer z.B. apache startet, können es alle anderen nicht mehr, ausser jeder Benutzer bekommt eine eigene IP. Und dann wären wir wieder bei vserver (uml, xen, ...) Wobei da auch noch das Problem bleibt, wie man die begrenzte Anzahl von öffentlichen IPs auf die privaten IPs umsetzt

[duergner]

Stimmt. Naja mir erschließt sich die Notwenigkeit dieser exterm vielen eigenen Installationen ja sowieso immer noch nicht.

[alexander newald]

Wenn ich mich richtig errinnere kann uml übrigens mit einer Datei ein FS System verwenden und dann für alle Instancen (ich sage jetzt mal vServer) nur die Änderungen speichern. Das würde zumindest schon mal helfen Festplattenspeicher zu sparen.

Aber 1000 shell User gleichzeitig auf einem System - Ob das dann immer noch performant läuft?

Bei der chroot Umgebung wäre auch noch zu klähren, ob das System mit der reinen Anzahl von Prozessen überhaupt klar kommt. Sagen wir mal 70 pro vServer mach bei 1000 Usern 70.000 Prozesse. Bei mir ist auf eine Testserver bei ca 2450 laufenden Prozessen Schluss

[Joe User]

Bei mir ist auf eine Testserver bei ca 2450 laufenden Prozessen Schluss

Ich bezweifle mal, dass Du ein System mit >= Quad-CPU/16GB RAM zur Verfügung hast ;)

[alexander newald]

Nicht so direkt (und indirekt auch nicht) :lol:

Aber es kommt dabei auch nicht so sehr auf den Speicherplatz, sondern auf die Anzahl an sich an. Einträge in der Prozesstabelle, Offene Dateien etc..

[ady1980]

Hallo,
Danke erstmal schonmal für die vielen Antworten!

Nun, bei den 1000 Usern, denen 24 Stunden zugang gewährt werden soll, muss ich noch erwähnen, das wir einkalkulieren können, müssen das im günstigsten Fall nicht alle aufeinmal auf der Maschine sein werden und der durchschnittskunde sich dann vielleicht 2 Stunden auf dieser Maschine aufhält.

Es geht halt was die performance angeht darum, das jdem dieser 1000, seine "Maschine" zur verfügung stehen muss, wenn er dann seine 24 Stunden nutzen möchte.

Ich vermute, das sich die 1000 über die 24 Stunden verteilen werden, so das vielleicht immer um die 300-400 wirklich zur gleichen Zeit auf der Maschine sind.

Wenn man dann sagt, ok, wir fahren eine UML erst hoch, wenn der User sich Anmeldet, dann müsste ich mir gedanken machen, wie man das lösen kann.

Im Idealfall können wir den Traffic auf mehrere Maschinen verteilen, da aber momentan das Geld fehlt, wird es wohl zunächst eine Maschine werden.