netdev - Re: Network virtualization/isolation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:  <5dirguseju.fsf@Hurtta06k.keh.iki.fi>
Date:	02 Dec 2006 13:49:41 +0200
From:	Kari Hurtta <hurtta+gmane@...lo.fmi.fi>
To:	netdev@...r.kernel.org
Subject:  Re: Network virtualization/isolation

Kari Hurtta <hurtta+gmane@...lo.fmi.fi> writes in gmane.linux.network:

> ebiederm@...ssion.com (Eric W. Biederman) writes in gmane.linux.network:
> 
> > Ok.  So on this point we agree.  Full isolation at the network device/L2 level
> > is desirable and no one is opposed to that.
> > 
> > There is however a strong feeling especially for the case of application
> > containers that something more focused on what a non-privileged process can
> > use and deal with would be nice.  The ``L3'' case.
> > 
> > I agree that has potential but I worry about 2 things.
> > - Premature optimization.
> > - A poor choice of semantics.
> > - Feature creep leading to insane semantics.
> > 
> > I feel there is something in the L3 arguments as well and it sounds
> > like it would be a good idea to flush out the semantics.
> > 
> > For full network isolation we have the case that every process,
> > every socket, and every network device belongs to a network namespace.
> > This is enough to derive the network namespace for all other user
> > visible data structures, and to a large extent to define their semantics.
> > 
> > We still need a definition of the non-privileged case, that is compatible
> > with the former definition.
> > 
> > .....
> > 
> > What unprivileged user space gets to manipulate are sockets.  So perhaps
> > we can break our model into a network socket namespace and network device
> > namespace.  
> > 
> > I would define it so that for each socket there is exactly one network
> > socket namespace.  And for each network socket namespace there is exactly
> > one network device namespace.
> > 
> > The network socket namespace would be concerned with the rules for deciding
> > which local addresses a socket can connect/accept/bind to.
> > 
> > The network device namespace would be concerned with everything else.
> 
> There need decide one thing:  What is connection between  namespaces?
> 
>     - Connection between the network device namespaces is bridge.
> 
>     - What (socket) is connection between the network socket namespaces?
> 
> Connection inside on name namespace is clear I think.
> 
>      - Connection inside of network device namespaces is loopback device.
> 
>      - Connection inside of network socket namespaces is socket
>        using loopback address(es)?


On other hand bridge between the network device namespaces need to set
on parent namespace.

So it is logical that connecting socket between network socket namespaces
is set on parent namespace.    So connecting socket is any socket created 
on parent namespace?   (socketpair() for example? )


( Currently socketpair()  allows only create AF_UNIX  sockects, which
  are not part of network socket namespace, I think) 

/ Kari Hurtta

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html