Stack virtualization (was: running out of mbufs?)

[Christian Kratzer]

Hi,

On Wed, 10 Aug 2005, Jeremie Le Hen wrote:

> On Wed, Aug 10, 2005 at 03:30:32PM +0200, Christian Kratzer wrote:
>>>> And of course IPv6 for jails is something that could propably be solved
>>>> in a very clean way using virtual ip stacks as in Marcos patch.
>>>
>>> I'll cook something up that uses interface groups and then you can judge
>>> whether it meets you needs or not.  It would be more lightwigth than having
>>> a full network stack per jail.
>>
>> Yes I can imagine Interface groups coming in handy in firewall setups.
>> You will propably not be able to provide clean semantics for INADDR_ANY
>> with anything but a dedicated virtual stack.
>>
>> A full network stack per jail provides the same semantics as in an
>> environment without jails and all the security of clean separation.
>> A little overhead for security is something I am very willing to pay ;)
>
> Both approach will require the ability to prevent jailed processes to
> do certain actions on their virtual interface/stack, such as adding a
> new IP address, because it has a noticable impact on the real network.
>
> I think this could be the job of the MAC framework (although I must
> admit that I never played with this), but I'm a little bit scared about
> the administrative overhead this would introduce for managing jails.

yes a jail with its own ip stack could mess up a network as much as a 
separate machine on the same network could today.

Virtual network stacks would primarily bring clean separation and consistent 
semantics to jails for cases where we require multiple IPv4, IPv6 ips and 
other protocols.  This would be a good thing.

One reason multiple IPv4 and especially IPv6 have been missing from jails 
is propably because the current very simple concept (converting all binds to 
inaddr_any to the jails ip) does not scale.  Interface groups would not help 
in this area.

As to inhibiting a jail from changing its stack so as not to disturb
the network. This would indeed need to be addressed perhaps through
a mac framework of some kind.

Greetings
Christian

-- 
Christian Kratzer                       ck at cksoft.de
CK Software GmbH                        http://www.cksoft.de/
Phone: +49 7452 889 135                 Fax: +49 7452 889 136