Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Figuring out the solution to in-network-sandbox distcc
Date: Wed, 21 Jan 2015 10:05:54
Message-Id: 20150121110534.09f0d16f@pomiot.lan
1 Hello, developers.
2
3 As you may recall, the main blocker for wide-establishment of
4 FEATURES=network-sandbox prohibiting network access within the build
5 environment is distcc. Since all connectivity is disabled, distcc can
6 no longer reach other distcc servers and build efficiently. I therefore
7 find it important to figure out a solution.
8
9 I see two generic approaches possible here:
10
11 1. proxying distcc from within the build environment, or
12
13 2. moving distcc-spawned processes back to parent's namespace.
14
15
16 distcc client/server solution
17 -----------------------------
18
19 The most obvious solution to me is to employ a client/server model
20 where a system-wide daemon is running, parsing /etc/distcc/hosts
21 and doing all the network activity. Clients can only connect to it via
22 a UNIX socket. While at it, we also make it responsible for task
23 scheduling so that parallel builds don't go over the task limits,
24 and maybe even integrate into distccd so that it is both aware of local
25 and remote builds.
26
27 Of course, that's a pipe dream assuming there will be somewhere to do
28 all the work, upstream will accept it and users will accept some
29 limitations (like no easy per-process overrides of DISTCC_HOSTS). So
30 better to look into something more realistic.
31
32
33 Generic proxy solution
34 ----------------------
35
36 The simplest solution so far seems to be setting a generic SOCKS proxy
37 inside the build environment, and wrapping distcc so that it will use
38 it for network access.
39
40 Unless we do some extra magic which don't want to do, this means that
41 other apps can also abuse the proxy to reach outside sandbox. However,
42 network-sandbox is not really a security feature, so I don't think that
43 is important. At least as long as we don't export it globally :).
44
45 Of course, software is a problem. We'd need at least some SOCKS server
46 for Portage (at least a very simple one), and as far as I'm aware
47 distcc does not support SOCKS directly, so tsocks in addition to that.
48
49
50 Parent namespace solution
51 -------------------------
52
53 The alternative is to wrap distcc so that parent network namespace is
54 regained. Sadly, for a start this requires SYS_CAP_ADMIN and access to
55 parent's /proc entry (so root privileges).
56
57 We obviously don't want to lose userpriv, so we have to do with setuid
58 wrapper. Of course, setuid wrappers need to be written in C, so we need
59 to introduce C compiled executable in Portage. Then we need to take some
60 special care for it not to be abused, e.g. to access restricted network
61 namespaces of other processes.
62
63
64 Any other ideas?
65
66 --
67 Best regards,
68 Michał Górny

Replies