Re: Thinking about "branes" for netbsd...

[Darren Reed <darrenr%netbsd.org@localhost>]

On 5/05/2012 4:24 AM, Mouse wrote:
>>> By not stopping at "I can configure this policy", but rather going
>>> all the way to "No other policy can possibly be configured" I think
>>> you make the mechanism less generally useful and I'd sort of like to
>>> see the justification for that.
>> You're right, it isn't desirable to be so restrictive.
> 
> I agree.  It strikes me as rather restrictive to mandate that which
> routing table is used is tied to which process is responsible for the
> traffic - especially since sockets can be shared by multiple processes,
> meaning that either you have to somehow forbid the same socket from
> appearing in the open file tables of processes using different branes,
> or you have to tag the data in the socket's send queue with which brane
> the writing process was in at the time of writing, or you have to
> attach branes to sockets as well as processes, or you have to make the
> brane association work only for immediately-sent traffic (eg, UDP but
> not TCP), or something of the sort.

It would appear that various people did not fully read what I proposed
or perhaps misunderstood it. What I wrote is that a brane would become
an entire instance of networking and that global structures, etc, would
disappear. If it helps you (or others) to understand it by thinking of
branes in terms of support for virtual routers then I'm happy for you
to do so but it is by no means limited to that.

For the purposes of this and other discussion, I consider the default
brane to be the networking environment that is created at boot.

In that context, if a process belongs to a brane then all of its sockets,
etc, would also belong to the new brane. Given that it is proposed that
a network interface can only ever belong to one brane, there are no issues
with respect to traffic leaking from one to another and the routing table
is fully self contained within the brane.

Given that there are security implications for being able to pass a
socket as a file descriptor from one process to another where the
two processes belong to different branes, that behaviour would need
to be prevented.

What I proposed in terms of a brane is much more than just support for
virtual routing - it takes NetBSD further along the path of being able
to support something like a jail. Whilst what I proposed in terms of a
brane is not enough to support a jail, it does alter the kernel's
networking in such a way as to make moving forward and implementing
something akin to jails for NetBSD easier.

To fully support jails would require further work on IPC, limiting
which processes can signal other processes, etc.

Consider the implementation of a branes for NetBSD being kernel level
virtualisation for networking and a step along the jail path.

Darren