Re: FreeBSD - "Experimentelle Features" - und Hackingtest

Peter Ross wrote:
> Hi,
>
> ich bastele gerade an "Automatisierungsideen".
>
> Dabei spielemn ein paar Technologien eine Rolle, die immer noch als
> "experimentell" gelten.
>
> VIMAGE und BHyve sind meine Kandidaten.
>
> Ich selbst habe VIMAGE seit ein paar Jahren verwendet. Meines Wissens gibt
> es dabei Probleme mit pf (was ich dann vermieden habe).. sonst sind mir
> keine grundlegenden Probleme bekannt.
>
> Ich frage mich hier, wie sicher es ist, wenn man ein Jail einem "Fremden"
> ueberlaesst (bis jetzt war mein Jail immer "meins", und so nur eine
> zusaetzliche Sicherheitsschicht, ich habe nicht darauf allein vertraut.)

Gute Frage.

Das Containment von Jails ist generell sehr gut, wenn man
ein paar Dinge beachtet und auf das Tuning achtet.
Die ganzen Jail-Parameter -- speziell "allow.*" -- sind Dir
sicherlich bekannt, daher gehe ich darauf jetzt nicht ein.

Eines der Probleme von Jails ist, dass man die Nutzung von
geteilten Resourcen (noch) nicht so gut kontrollieren kann.
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.

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=...). Aber das skaliert nicht besonders gut,
wenn man sehr viele Jails auf einem Host betreiben will.
(Diesen Nachteil haben allerdings auch "klassische" Virtuali-
sierungen wie VirtualBox, VMware usw.)

Ähnliches gilt für die gemeinsame Resource CPU. Mit cpuset
kann man Jails immerhin auf bestimmte Prozessoren und/oder
Kerne festnageln, so dass sich der Schaden in Grenzen hält,
wenn ein Jail aus dem Ruder läuft. Und das Netzwerk kann man
mit IPFW + Dummynet kontrollieren. Eine häufige Empfehlung
ist, Jails generell nur eine localnet-Adresse zu geben (aus
127.0.0.0/8), die prinzipiell nicht geroutet wird, und per
IPFW-Forwarding-Regeln festzulegen, welcher Traffic ins Jail
rein und wieder raus darf. Ich mache das meistens so.

Prozessbasierte Virtualisierungen (BSD Jails, Solaris Zones)
haben viele Vorteile, aber man sollte immer im Hinterkopf
behalten, dass alles unter demselben Kernel läuft. 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.

Übrigens, DragonFly BSD ist hier teilweise schon ein bisschen
weiter. Zum einen hat es ein "Disk I/O Scheduler Framework"
(dsched), mit dem man den Disk-I/O von Prozessen und Jails
tatsächlich einschränken kann. Dazu gibt es ein Tool ioprio.
Das andere interessante Feature nennt sich VKERNEL und erlaubt
das Ausführen von Kernels im Userland, ähnlich wie Usermode
Linux (UML). Die Ebene der Trennung liegt hier irgendwo in
der Mitte zwischen Jails und VM-basierter Virtualisierung.

Zu BHyve kann ich leider noch nicht viel sagen; ich kenne es
nur aus der Dokumentation und von Berichten anderer, aber ich
habe noch nicht selbst damit gearbeitet. Der Beschreibung
und dem Hörensagen nach klingt es schon sehr vielversprechend
und durchaus schon für den Praxiseinsatz geeignet, aber für
mich persönlich wird es wohl erst dann interessant, wenn man
darunter auch "fremde" Systeme laufen lassen kann. Bisher
funktioniert offenbar nur FreeBSD selbst als Gastsystem.

Gruß
   Olli

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