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 (g_at_netcraft.com.au)
Date: Sun Mar 10 2002 - 08:41:51 EST


On Sun, Mar 10, 2002 at 03:15:16PM +1100, edward_at_paradigm4.com.au 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 127.0.0.1 on
> the same machine.
>
> Starting from ctx-8, vservers are unable to connect and use such
> services, because when they try to connect to 127.0.0.1 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 127.0.0.1 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:

127.0.0.1 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:

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

Geoffrey's Suggested behaviour #1:

Map 127.0.0.1 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 127.0.0.1, then:
- attempt to connect to 127.1.y.z instead
- if the connection succeeds, good
- if the connection fails, attempt to connect to 127.0.0.1 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 127.0.0.1:53
  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               geoffrey_at_netcraft.com.au
Senior Systems Engineer           http://www.netcraft.com.au/geoffrey/
NetCraft Australia Pty Ltd           http://www.netcraft.com.au/linux/

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