Re: [vserver] vserver 0.11 and kernel ctx-8 released

About this list Date view Thread view Subject view Author view Attachment view

From: Geoffrey D. Bennett (
Date: Sun Mar 10 2002 - 08:41:51 EST

On Sun, Mar 10, 2002 at 03:15:16PM +1100, wrote:
> This change is causing problems.

> Situation 1:
> You have some common services used by vservers, e.g. dns
> cache/resolver, database backend etc.., listening on on
> the same machine.
> Starting from ctx-8, vservers are unable to connect and use such
> services, because when they try to connect to it is
> remapped to their pubic IP addresses.

> Situation 2:
> Usually when application needs to create a "private" service it
> binds to localhost. With previous kernels, it would fail. With
> ctx-8, it succeeds but instead of listening on localhost, it opens
> up a port on public interface, which is not what application
> expects. This could have dire security consequences. I'd rather it
> failed than succeeded with unexpected result.
> Could you make this particular bits, i.e. remapping bind and route
> of optional? Either at kernel build time or at runtime?

If anyone's interested in my two cents :), this is how I see it:

Old behavour: is shared by all vservers. This is good for sharing local
services as pointed out above, but allowing communications between
vservers may be bad from a security POV.

Current behaviour: gets mapped to the public address. This is really bad, as
also pointed out above.

Geoffrey's Suggested behaviour #1:

Map to something like 127.1.y.z for bind() and connect() --
y.z could just be the context number (since MAX_S_CONTEXT is only
65535). Firewalling rules could then disallow communication between
127.1.a.b and 127.1.c.d where a.b != c.d. This would fix the security
problems with both the old behaviour and the current behaviour, but
would prevent the implementation of shared local services.

Geoffrey's Suggested behaviour #2:

As for #1, but: change connect() so that if the address being
connected to is, then:
- attempt to connect to 127.1.y.z instead
- if the connection succeeds, good
- if the connection fails, attempt to connect to as usual

This suggestion is obviously a bit more complicated, but would allow
some nice things; for example:
- named running in root vserver
- most vservers not running named, hence connections to
  going to the root vserver named
- some vservers running their own copy of named, "overriding" the root
  vserver named with their own

Have fun,

Geoffrey D. Bennett, RHCE, RHCX     
Senior Systems Engineer 
NetCraft Australia Pty Ltd 

About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:01 EDT