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

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

From: Nick Craig-Wood (
Date: Mon Mar 11 2002 - 04:42:15 EST

On Mon, Mar 11, 2002 at 12:11:51AM +1030, Geoffrey D. Bennett wrote:
> 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.

...and binding to fails

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

...and binding to succeeds, but it doesn't actually bind to I agree that this is bad. Anyone using or
localhost explicitly expects it not to be a public service.

> 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.

I prefer the slight modification that a bind to is remapped
to 127.b.c.d where b.c.d is the low 24 bits of the ipv4 address. This
means that all vservers who can bind to a.b.c.d can bind to 127.b.c.d
also which is a more logical grouping than security context. It also
means that you can ifconfig the interfaces in advance.

If you re-ifconfig lo to have a /32 rather than a /8 you can bring up
the new lo interfaces. I have a nameserver bound to on this

  # lo configured as as default
  ping # works
  ping # works
  ifconfig lo netmask up
  ping # fails
  ping # fails
  ifconfig lo:1 netmask up
  ping # works
  dig something @ # works
  dig something @ # fails

> 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

This would cause big trouble I think - what happens if named dies
unexpectedly on your vserver? Now all of a sudden requests are going
to the main named but no-one knows!

Nick Craig-Wood

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