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:  <5dmz66sfi9.fsf@Hurtta06k.keh.iki.fi>
Date:	02 Dec 2006 13:29:02 +0200
From:	Kari Hurtta <hurtta+gmane@...lo.fmi.fi>
To:	netdev@...r.kernel.org
Subject:  Re: Network virtualization/isolation

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)?

/ 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