Hello, On Sun, 11 May 2014 23:42:38 +0200 Michał Górny wrote: > Hi, everyone. > > Almost 9 months ago I've committed three new FEATURES for portage: > cgroup, ipc-sandbox and network-sandbox. Today I'd like to propose > enabling at least the latter two by default. > > > Firstly, I'd like to shortly remind you what they do: > > 1. cgroup -- puts all processes spawned by ebuild to cgroup, and kills > all of them once phase exits (prevents leaving orphans), > > 2. ipc-sandbox -- puts all processes spawned by ebuild to a separate > IPC namespace, preventing them from interfacing other system services > via IPC (message queues, semaphores, shared memory), > > 3. network-sandbox -- puts all processes spawned by ebuild to > a separate network namespace with a private loopback interface, > preventing them from interfacing other system services, local network > and the Internet. > > > Secondly, the benefits of using the latter two include: > > 1. improved tree quality through more complete testing > > In the past, usually users with no or shoddy Internet access were > the first to notice ebuilds breaking with no Internet access. With > network-sandbox, the ebuilds fail consistently for everyone including > developers. They can notice the issues first hand and fix them before > committing the ebuild to the tree. > > 2. protection of user privacy (and security) > > Currently, programs spawned by ebuilds can submit any data > to the Internet, often unnoticed. While committing ebuild performing > malicious activity is unlikely, such uses as test suites sending > pre-defined data and possibly some system-specific data to remote > services happen. This affects user's privacy and we should prevent > ebuilds from doing that without user's approval. > > 3. preventing unsolicited (and possibly costly) Internet access > > Bear that Gentoo can be run on a machine with byte-paid or otherwise > shoddy Internet access (possibly with local distfile host or alike). > Ebuilds using network unwisely can reduce throughput of other local > services or even cause higher Internet bill. > > 4. improving security through preventing unsolicited access > > The build process (and especially tests) can spawn daemons and bind > them to network interfaces. Without network sandbox, other processes > (or systems if 0.0.0.0/:: is used) can access the spawned services > and possibly perform malicious operations. With network-sandbox, even > local users can't access the spawned daemons (due to private loopback > interface). > > 5. preventing data loss through thoughtless access to local services > > I have seen test suites that used production database servers running > on the host. You can imagine how much damage such a test suite could > cause by mistake. network-sandbox prevents the ebuild from accessing > local services, requiring it to run a safe, separate instance. > > > What do you think?
Please do not enable them prior rigorous testing. I tried network-sandbox — this is a disaster. It brokes distcc completely since distcc client can't connect to remote servers (and even to a local one if any). Best regards, Andrew Savchenko
pgpbJV0RefLor.pgp
Description: PGP signature
