Re: FreeBSD - "Experimentelle Features" - und Hackingtest

Peter Ross wrote:
> Oliver Fromme wrote:
> > Eines der Probleme von Jails ist, dass man die Nutzung von
> > geteilten Resourcen (noch) nicht so gut kontrollieren kann.
>
> Es gibt rctl(8), damit laesst sich fuer Speicher und CPU doch eine Menge
> "erschlagen". Fuers Netz gibt es Paketfilter mit QoS.

rctl ist ein guter Ansatz, aber in der Praxis noch ziemlich
knifflig. Man möchte ja normalerweise, dass produktive
Dienste (z.B. ein Apache + Tomcat), die in einem Jail laufen,
nicht sofort gekillt werden, wenn sie mal aufgrund hoher
Anfragen mal mehr Resourcen haben wollen. Wünschenswerter
wäre, sie ggf. nur zu "bremsen", wenn sie ein gewisses Limit
erreichen, das z.B. per SLA festgelegt ist. Das ist mit rctl
leider schwierig (evtl. auf Umwegen mit devd/devctl und ein
bisschen Scripting, aber alles andere als trivial).

> > Prozesse in Jails können z.B. intensiv auf der Festplatte
> > herumhämmern und auf diese Weise DoS-ähnliche Szenarien
> > verursachen. Es fehlt noch eine Art Dummynet für Disk-I/O.
>
> Speziell fuer Disk I/O muss ich noch einmal gucken.
>
> > Man kann das Problem natürlich eindämmen, indem man einem
> > Jail seine eigene HDD oder SSD gibt, oder dem Jail eine RAM-
> > Disk (TMPFS) verpasst, deren Größe natürlich beschränkt sein
> > muss (-o size=...).
>
> Ich denke da noch mal drueber nach.. im Moment faellt mir nur ein, dass
> auch ZFS selbst eine Menge im RAM macht (ARC).
>
> Man kennte eventuell das Problem mit "ein zpool pro jail" angehen, mit
> separaten ZILs auf SSD. Eventuell koennte man da an den Parameters weiter
> drehen?

Meines Wissens (ich könnte mich aber irren; es gibt ja regel-
mäßig neue Features) gibt es keine Möglichkeit, z.B. die Anzahl
der IOPS zu begrenzen, oder gar die physikalische Auslastung
einer Festplatte. So etwas wäre aber eigentlich notwendig, um
die Festplatte als shared resource fair auf eine Anzahl von
Nutzern (Jails) aufzuteilen.

> > Wenn ich
> > Shell-User in ein Jail hereinlasse, denen ich nicht traue,
> > oder von denen ich sogar weiß, dass sie "Böses" versuchen
> > werden, dann würde ich die ganze Kiste, also auch das Host-
> > System, als Feindesland betrachten. Daran ändert auch VIMAGE
> > nichts.
>
> In einer Hosting-Umgebung (z.B.) kommt es ja vorallem darauf an, dass
>
> - ein Nutzer nicht das ganze System in den Abgrund reissen kann
> - ein Nutzer nicht alle Resourcen "verbraten" kann (Prozessor, Speicher,
> Disk.. habe ich was vergessen?)

Wichtig wäre noch das Netzwerk, d.h. in erster Linie Traffic
(Bandbreite), aber evtl. auch Dinge wie die Anzahl gleichzeitig
offener Sockets usw.

> - ein Nutzer nicht die Virtualisierungsumgebung kompromitieren kann,
> - ein Nutzer nicht auf die Bereiche anderer Nutzer zugreifen kann.
>
> Habe ich hier was vergessen?
>
> Ich wuerde mit Sicherheit zusaetzliche Massnahmen ergreifen, um auch die
> Hosts voneinander zu isolieren.

Um es nochmal ganz klar zu sagen: Eine Hosting-Umgebung, in
die sich "fremde" User einloggen können, würde ich nicht mit
Jails allein machen. Und wenn doch, würde ich keine Garantien
für die Integrität des Host-Systems und der Jails untereinaner
machen.

In solchen Fällen würde ich dann doch eher zu VirtualBox, Qemu
oder ähnlichem greifen. Möglicherweise auch zu so etwas wie
UML bei Linux oder VKERNEL bei DragonFly, wobei es etwas
Vergleichbares bei FreeBSD (oder BSD allgemein) leider nicht
gibt.

> Nebenbei stellt isich fuer mich dfie Frage, wie sicher
> Linux(CentOS6-)jails waeren. Da ich dafuer z.B. procfs brauche..: weicht
> das die Sicherheit von Jails auf? (Ich vermute, ja, aber das ist kein
> Wissen).

procfs ist so ein Reizthema ... Linux packt ja alles mögliche
in sein procfs, ob es Sinn ergibt oder nicht (meistens eher
nicht). FreeBSD verwendet für solche Dinge sysctl, was
sinnvoller und nicht zuletzt auch performanter ist.

Für das Thema Sicherheit spielt es prinzipiell erstmal keine
Rolle, ob Daten aus dem procfs oder von sysctl kommen. Aber
mein persönlicher Eindruck ist, dass bei sysctl eher darauf
geachtet wird; es ist quasi Standardpraxis, beim Einrichten
einer neuen sysctl-Variablen geeignete "prison checks" mit
einzufügen. Beim procfs von Linux dagegen kann ich mich des
Eindrucks nicht erwehren, dass dort ein gewisser Wildwuchs
herrscht. Aber das ist nur subjektiv; ich kann es nicht
konkret festnageln.

> > Übrigens, DragonFly BSD ist hier teilweise schon ein bisschen
> > weiter.
>
> Da ich aus Zeitgruenden hier keinen Blick drauf geworfen habe.. wie geht
> es bei DragonFlyBSD voran?

Langsam aber stetig. DragonFly hat leider nicht so viele
Developer wie FreeBSD. Das "Hauptprojekt" von Matt Dillon ist
zur Zeit HAMMER2, die zweite Inkarnation seines Dateisystems,
bei dem nun auch Features für seine Vision eines SSI (Single
System Image) im Vordergrund stehen.

SSI heißt, dass sich ein Cluster aus mehreren Nodes wie ein
einziges, kohärentes System mit gemeinsamen Resourcen verhält.
Man loggt sich nicht mehr auf einem Rechner ein, sondern auf
dem Cluster. Auf welchem der Rechner dann der Shellprozess
läuft, weiß man im voraus nicht, und er kann bei Bedarf auch
jederzeit von einem Node zu einem anderen wechseln, ohne dass
man es merkt. HAMMER2 wird ein großer Schritt sein, um dies
zu ermöglichen.

Ich habe mir Matt's Paper über das Design von HAMMER2 durch-
gelesen, und ich habe den Eindruck, dass er weiß, was er tut.
:-)

> Es gibt also Jails, VKERNEL.. HAMMER, aber kein ZFS?

Richtig. Da HAMMER viele Features von ZFS hat (und sogar
einige, die ZFS nicht hat), hat sich niemand die Mühe gemacht,
ZFS zu portieren.

DragonFly hat eine Reihe weiterer interessanter Features,
z.B. Variant Symlinks und Process Checkpointing. Aber das
nur am Rande, es hat nicht direkt mit Virtualisierung oder
Jails zu tun.

Gruß
   Olli

-- 
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message