Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc

[Michał Górny]

Dnia 2015-01-22, o godz. 00:34:35
Luis Ressel <aranea@×××××.de> napisał(a):

> On Wed, 21 Jan 2015 10:38:20 -0500
> Rich Freeman <rich0@g.o> wrote:
>
> > On Wed, Jan 21, 2015 at 10:00 AM, Alexis Ballier
> > <aballier@g.o> wrote:
> > > On Wed, 21 Jan 2015 11:05:34 +0100
> > > Michał Górny <mgorny@g.o> wrote:
> > >
> > >> Hello, developers.
> > >>
> > >> As you may recall, the main blocker for wide-establishment of
> > >> FEATURES=network-sandbox prohibiting network access within the
> > >> build environment is distcc. Since all connectivity is disabled,
> > >> distcc can no longer reach other distcc servers and build
> > >> efficiently. I therefore find it important to figure out a
> > >> solution.
> > >>
> > >> I see two generic approaches possible here:
> > >>
> > >> 1. proxying distcc from within the build environment, or
> > >>
> > >> 2. moving distcc-spawned processes back to parent's namespace.
> > >
> > >
> > > I haven't followed this at all, so this might be very stupid:
> > > Isn't it possible to whitelist distcc hosts ?
> >
> > That would only work with a proxy of some kind.
> >
> > A process running in a separate network namespace doesn't see any
> > network interfaces.  It can't even get as far as iptables/etc for some
> > kind of filtering.  Now, you could define an interface in the new
> > namespace, and then bridge that to the host network, and then apply
> > iptables rules to it.
> >
>
> Your last sentence mentions a nice possibility:
> 1) Connect the sandbox network namespace to the global namespace (using
>    a veth pair?)
> 2) Enable forwarding (if I understand it right, it's even possible to
>    do this for individual interfaces instead of globally, using
>    /proc/sys/net/ipv{4,6}/conf/veth0 )
> 3) Set up suitable rules in the netfiler FORWARD chain to ensure only
>    distcc gets through
> 4) Set up SNAT or MASQUERADE in netfilter's nat table
> 5) There you go!
>
> This is beautiful because is doesn't require any userland proxies, but
> of course, it would be difficult to set up in an automated fashion. So

Yes, and it involves changing host's configuration which I would really
like to avoid. It should be something that can be done purely
in network namespace of the build, and securely, and without having to
parse distcc configuration, and without extra kernel features...

-- 
Best regards,
Michał Górny