Re: FreeBSD - "Experimentelle Features" - und Hackingtest

Hi,

danke fuer die Antworten.

Oliver Fromme wrote:
> 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.

Ja.

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

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

Ich habe aber noch nie mit vielen zpools gearbeitet und weiss nicht, ob
das effektiv ist.

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

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

> Ü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?

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

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

Danke nochmal
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 10 Sep 2015 - 01:13:17 CEST