Subject: Re: [vserver] vserver git server and misc. thoughts
From: "Daniel Hokka Zakrisson" <daniel@hozac.com>
Date: Tue, 12 Aug 2008 21:05:45 +0200 (CEST)

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