netdev - Re: [RFC net-next 0/3] Proposal for VRF-lite

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]

Date:	Tue, 09 Jun 2015 14:43:14 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Thomas Graf <tgraf@...g.ch>,
	Shrijeet Mukherjee <shm@...ulusnetworks.com>
Cc:	David Ahern <dsahern@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jamal Hadi Salim <hadi@...atatu.com>, davem@...emloft.net,
	Stephen Hemminger <stephen@...workplumber.org>,
	netdev@...r.kernel.org, roopa@...ulusnetworks.com,
	andy gospodarek <gospo@...ulusnetworks.com>,
	jtoppins@...ulusnetworks.com, nikolay@...ulusnetworks.com
Subject: Re: [RFC net-next 0/3] Proposal for VRF-lite

On Tue, Jun 9, 2015, at 14:30, Nicolas Dichtel wrote:
> Le 09/06/2015 12:15, Thomas Graf a écrit :
> > On 06/08/15 at 11:35am, Shrijeet Mukherjee wrote:
> > [...]
> >> model with some performance paths that need optimization. (Specifically
> >> the output route selector that Roopa, Robert, Thomas and EricB are
> >> currently discussing on the MPLS thread)
> >
> > Thanks for posting these patches just in time. This explains how
> > you intent to deploy Roopa's patches in a scalable manner.
> >
> >> High Level points
> >>
> >> 1. Simple overlay driver (minimal changes to current stack)
> >>     * uses the existing fib tables and fib rules infrastructure
> >> 2. Modelled closely after the ipvlan driver
> >> 3. Uses current API and infrastructure.
> >>     * Applications can use SO_BINDTODEVICE or cmsg device indentifiers
> >>       to pick VRF (ping, traceroute just work)
> >
> > I like the aspect of reusing existing user interfaces. We might
> > need to introduce a more fine grained capability than CAP_NET_RAW
> > to give containers the privileges to bind to a VRF without
> > allowing them to inject raw frames.
> >
> > Given I understand this correctly: If my intent was to run a
> > process in multiple VRFs, then I would need to run that process
> > in the host network namespace which contains the VRF devices
> > which would also contain the physical devices. While I might want
> > to grant my process the ability to bind to VRFs, I may not want
> > to give it the privileges to bind to any device. So we could
> > consider introducing CAP_NET_VRF which would allow to bind to
> > VRF devices.
> 
> If I understand correctly, all existing applications should also be
> modified
> if I want to run them into a VRF/MRF (see my previous email)?
> 
> ssh, dhcp, httpd, etc should be runnable per MRF without modifications of
> their source code. So, it becomes a netns. What's about an IKE dameon?
> 
> It makes sense to have both: netns and MRF ; each can have their own
> logics
> of VRF-like behavior depending on how a VRF is defined by the end users.

Agreed, the idea is to have a prctl in the end which gets inherited by
fork. current->rt_table_id or some kind of vrf specifier in task_struct
would make that possible then.

A helper tool like ip route exec table 100 /bin/bash would then start a
session bound to a specific routing instance.

Bye,
Hannes
--
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