[gentoo-dev] RFC: enabling ipc-sandbox & network-sandbox by default

[Michał Górny]

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