Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
Date: Sat, 24 Jan 2015 11:03:41
Message-Id: 20150124120327.7b4e7860@pomiot.lan
In Reply to: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc by "Michał Górny"
1 Dnia 2015-01-21, o godz. 11:05:34
2 Michał Górny <mgorny@g.o> napisał(a):
3
4 > Parent namespace solution
5 > -------------------------
6 >
7 > The alternative is to wrap distcc so that parent network namespace is
8 > regained. Sadly, for a start this requires SYS_CAP_ADMIN and access to
9 > parent's /proc entry (so root privileges).
10 >
11 > We obviously don't want to lose userpriv, so we have to do with setuid
12 > wrapper. Of course, setuid wrappers need to be written in C, so we need
13 > to introduce C compiled executable in Portage. Then we need to take some
14 > special care for it not to be abused, e.g. to access restricted network
15 > namespaces of other processes.
16
17 I've started to work on this, and I have all the setup.py code ready.
18 Now it's just the C program and wrapping it all in Portage.
19
20 The only remaining big issue is how to pass the correct namespace (or
21 PID) to the distcc process, assuming it may be a deep child of
22 the ebuild process.
23
24 Possibilities:
25
26 1. Environment variables. Can't do because:
27
28 a. one of the parent processes may scrub the environment,
29
30 b. malicious process may override the variable, giving subprocess
31 access to restricted system network namespace.
32
33 2. Files. Can't do because we would have to pass the path somehow (see
34 1.), and if we go for static path, we have collisions between multiple
35 emerge processes.
36
37 3. Parent process hierarchy. Seems fragile, requires a lot of scanning
38 on every spawn and may end up in the wrong namespace if a subprocess
39 calls setsid() and user put emerge in a separate namespace.
40
41 4. IPv4 socket. While it may seem a real dumb idea, it fits the case
42 perfectly since it is only run if process is network-namespaced. We can
43 surely reserve a static port early and run a daemon outputting
44 the correct PID. Since the port is namespaced, every Portage process
45 can have its own PID-daemon, and I don't know if there's any way of
46 overriding the result from parent process.
47
48 Any other ideas?
49
50 --
51 Best regards,
52 Michał Górny

Replies

Subject Author
Re: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc Andrew Savchenko <bircoph@g.o>