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? -- Best regards, Michał Górny
signature.asc
Description: PGP signature
