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

[Rick \\\"Zero_Chaos\\\" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/11/2014 05:42 PM, 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?
>
I love these new features, with one minor question:

What about talking to local network resources?  In my metasploit ebuild
it has tests available which talk to a local database and are perfectly
safe, however, if postgresql is started on the system the tests don't
work, the ebuild needs to start it's own postgresql to run the tests.
This seems a bit needless in my package, but likely saves others from
poorly written tests.  Do we want to allow access to system network
services or block them? Right now they are blocked, and that's going to
make the src_test function on my ebuild expand into near insanity to fix.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTcPGvAAoJEKXdFCfdEflKTRsQALVP4yDmT+KIbd5ZnEj0TlUf
6eiG2pVJ1XHun3cuil4Sm5AqbuehvhzCLzM8uLEZuTus8YIZqfO4XhiXjY70WyMM
N1SdUMFucmokOvNG2RmTVt30VETAn2fOQakbpYu7KyR2N9lDtAi/UXfJJTGRe+m3
iilVZ8rRyQG903VRwJZoQsYPjv7qYwxC7I345u3jDpwwObnbvs9An5lE5A4gVSa/
oLHI636lkdO7e2egitewGEo96Xaa65CCVTt9w5BeT2Ovv3IwgxjD6UgO6hbYIHvg
CsdnCUTd1o3BTasZgAwaJJv8FcJWdrpJsEk8Kowb42Mpy6kaz7ymaxbOye3i07jf
MIdh+nbRUS3VRuUf14+8sda1/rCpgnOKIbGfNpfAuKFf/FNfTbLQET7cIv5oNAJE
Kis0nfLCSdZTxV9qlLC/7cxC8MNSjYu1x/ynRQYmK1qUTGfiWUqMwdk3HBveVAI8
bfYTtoXbbuyGHU2hOxRPgYl/ynVoWRw65jYZR5gLekXlVJtbU3H76NpbKqkYXWtF
l+u8ddJCGD3ghVUm8Sknk8E8uSGOxgHaRaIfj8HpVSKrn/BZkB8dnmTa15SvQYUf
yBvuJTAMlSDkLXCvqJZJVK61iDc6eFPXXcsrOkrYNOpz3425AI4iuXHvtfpDJnGP
UgnWgSfIJ9iN0jHz7n0e
=uAgr
-----END PGP SIGNATURE-----