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

[Andrew Savchenko]

On Sat, 24 Jan 2015 12:03:27 +0100 Michał Górny wrote:
> Dnia 2015-01-21, o godz. 11:05:34
> Michał Górny <mgorny@g.o> napisał(a):
>
> > Parent namespace solution
> > -------------------------
> >
> > The alternative is to wrap distcc so that parent network namespace is
> > regained. Sadly, for a start this requires SYS_CAP_ADMIN and access to
> > parent's /proc entry (so root privileges).
> >
> > We obviously don't want to lose userpriv, so we have to do with setuid
> > wrapper. Of course, setuid wrappers need to be written in C, so we need
> > to introduce C compiled executable in Portage. Then we need to take some
> > special care for it not to be abused, e.g. to access restricted network
> > namespaces of other processes.
>
> I've started to work on this, and I have all the setup.py code ready.
> Now it's just the C program and wrapping it all in Portage.
>
> The only remaining big issue is how to pass the correct namespace (or
> PID) to the distcc process, assuming it may be a deep child of
> the ebuild process.
>
> Possibilities:
>
> 1. Environment variables. Can't do because:
>
>  a. one of the parent processes may scrub the environment,
>
>  b. malicious process may override the variable, giving subprocess
>  access to restricted system network namespace.
>
> 2. Files. Can't do because we would have to pass the path somehow (see
> 1.), and if we go for static path, we have collisions between multiple
> emerge processes.

If we're not going to use PID isolation in future, PID-dependent
"static" file name may be used, where PID belongs to emerge. This
should solve the collision issue.

> 3. Parent process hierarchy. Seems fragile, requires a lot of scanning
> on every spawn and may end up in the wrong namespace if a subprocess
> calls setsid() and user put emerge in a separate namespace.

Why not to use cgroups here?
 
> 4. IPv4 socket. While it may seem a real dumb idea, it fits the case
> perfectly since it is only run if process is network-namespaced. We can
> surely reserve a static port early and run a daemon outputting
> the correct PID. Since the port is namespaced, every Portage process
> can have its own PID-daemon, and I don't know if there's any way of
> overriding the result from parent process.

Looks fine, though the very idea to have extra daemons is
unpleasant.

Best regards,
Andrew Savchenko