> Wenn ich das richtig verstehe, kann ich dem gejailten Prog/Proz. eine
> eigene Wurzel zuordnen, so dass er im PRinzip nur Schaden ab da
> anrichten kann.
yep... jail(2) schafft die basis, den rest erledigt ganz normal
chroot(2)
> Wie sieht es dann mit nachzuladenden Modulen oder
> externen PRogrammen aus, die ja dann auch out of scope sein müssten?
ja/nein
wenn chroot(2) auf den selben pfad weisst, wie ein anderer gejailter
prozess,
koennen sich die beiden prozesse auf file-system ebene in die quere
kommen.
aber prozesstechnisch ist keine kommunikation moeglich. (ausnahme
netzwerk und eben das angesprochene filesystem problem)
> Die Intention von jail_Attach und der Bug ist nun auch klar. Danke.
> Allerdings kratze ich mich immernoch ein wenig am Kopf, denn
> jail_Attach bedeutet ja, dass, wenngleich von der admin-Seite her,
> zwie PRoz. in einem jail laufen und sich evtl. beeinflussen. ISt das
>Â schlau?
es ist korrekt, dass sich zwei prozesse in einem jail sehen und damit
beeinflussen koennen, das muss der admin immer im hinterkopf
behalten. in einigen faellen laesst sich das durchaus verantworten,
weil hier evtl. die bessere resourcennutzung ueberwiegt.
in anderen faellen mag das erwuenscht sein, das sich zwei prozesse
auf einem direkteren wege unterhalten, ohne den umweg ueber das netz
oder das filesystem.
man kann natuerlich streiten, ob jail_attach(2) wirklich notwendig
gewesen waere. die erweiterung von jail(2) fuehrt jedesmal zu
grundsatzdebatten im freebsd entwicklerteam. die einen sprechen sich
dafuer aus, die anderen sagen: keep it small, keep it simple, keep it
working!
ich kann beide seiten verstehen. jail(2) ist sicherheitstechnisch
sehr relevant und nach anfaenglichen leaks ist die
sicherheitsgeschichte extrem sauber.
jetzt hat man was hinzugefügt und prompt gibt es die erste
sicherheitsmeldung.
kritiker der erweiterung von jail(2) sehen sich darin bestaetigt.
man merkt: irgendwann werden betriebssysteme philosophisch.
so long
snoofy
> eigene Wurzel zuordnen, so dass er im PRinzip nur Schaden ab da
> anrichten kann.
yep... jail(2) schafft die basis, den rest erledigt ganz normal
chroot(2)
> Wie sieht es dann mit nachzuladenden Modulen oder
> externen PRogrammen aus, die ja dann auch out of scope sein müssten?
ja/nein
wenn chroot(2) auf den selben pfad weisst, wie ein anderer gejailter
prozess,
koennen sich die beiden prozesse auf file-system ebene in die quere
kommen.
aber prozesstechnisch ist keine kommunikation moeglich. (ausnahme
netzwerk und eben das angesprochene filesystem problem)
> Die Intention von jail_Attach und der Bug ist nun auch klar. Danke.
> Allerdings kratze ich mich immernoch ein wenig am Kopf, denn
> jail_Attach bedeutet ja, dass, wenngleich von der admin-Seite her,
> zwie PRoz. in einem jail laufen und sich evtl. beeinflussen. ISt das
>Â schlau?
es ist korrekt, dass sich zwei prozesse in einem jail sehen und damit
beeinflussen koennen, das muss der admin immer im hinterkopf
behalten. in einigen faellen laesst sich das durchaus verantworten,
weil hier evtl. die bessere resourcennutzung ueberwiegt.
in anderen faellen mag das erwuenscht sein, das sich zwei prozesse
auf einem direkteren wege unterhalten, ohne den umweg ueber das netz
oder das filesystem.
man kann natuerlich streiten, ob jail_attach(2) wirklich notwendig
gewesen waere. die erweiterung von jail(2) fuehrt jedesmal zu
grundsatzdebatten im freebsd entwicklerteam. die einen sprechen sich
dafuer aus, die anderen sagen: keep it small, keep it simple, keep it
working!
ich kann beide seiten verstehen. jail(2) ist sicherheitstechnisch
sehr relevant und nach anfaenglichen leaks ist die
sicherheitsgeschichte extrem sauber.
jetzt hat man was hinzugefügt und prompt gibt es die erste
sicherheitsmeldung.
kritiker der erweiterung von jail(2) sehen sich darin bestaetigt.
man merkt: irgendwann werden betriebssysteme philosophisch.
so long
snoofy