Martin Fick wrote: > --- On Tue, 8/12/08, Daniel Hokka Zakrisson <daniel@hozac.com> wrote: >> We're adopting the new namespaces/cgroups as soon as >> they're somewhat vetted for functionality. Currently, >> the biggest things missing from a vanilla kernel when >> compared to a Linux-VServer kernel are: >> - chroot barrier. Guests can escape to the host without >> much difficulty at all. >> - devpts virtualization/isolation. Guest A can access guest >> B's terminals. >> - network isolation. Network virtualization is in mainline, >> but that's more overhead maintenance- and CPU-wise, and it currently >> requires you to disable sysfs. >> >> Those are just some major, rather basic, things off the top >> of my head. > > What is the plan to deal with network virtualization. I understand that vserver network > isolation (chbind) is lighter weight than the new mainline virtual adapter/bridge > method, but now that this is already in mainline, are there any plans to enhance the > utilities to also be able to use this feature? In other words, if vserver can still > support the current light weight method great, but if it can take advantage of the > kernel methods without requiring patches that would be good too, wouldn't it? > Especially since I am sure, some vserver users will desire this extra heavier weight > solution. Once they're usable, the utils will support them. > As for the chroot barrier, perhaps I misunderstand things, but I thought that the chroot > directory vulnerability only existed when a program did not carefully enter a chroot? > If so, shouldn't the vserver utilities be able to ensure that this barrier is not > actually needed when using them? Are there still escape exploits even when doing things > right with chroot that are known (aside from mounting filesystems which can be limited > with capabilities) to easily escape vservers without a chroot barrier? Or are the > barriers just extra precautions to stop unanticipated cases? No, cd /; mkdir foo; chroot foo; cd ../../ works as documented (see chroot(2)) in all cases where CAP_SYS_CHROOT is available. The barrier is the only thing protecting the host and other guests from a compromised guest. -- Daniel Hokka Zakrisson