Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, 12 May 2014 19:39:09 +0200 Michał Górny mgo...@gentoo.org wrote: I don't know postgresql well enough but does the test db reside in temporary build directory? That is, can you guarantee that: 1) it will never ever collide with user's database, 2) it will be properly cleaned up even if the test suite terminates unexpectedly? The closest thing you could do would be to create a separate tablespace residing in the build directory. I wouldn't consider this a good idea however, as you'd need postgres superuser permissions, it would have some unintented side effects (like breaking on SELinux machines), you'd have to patch the test suites and it still wouldn't ensure an automatic cleanup -- on unexpected test suite terminations the dir in which the tablespace resides would vanish, but postgres would still expect one there, which might even create further problems (especially on re-emerge). I wouldn't recommend using this approach even when accessing the host postgres. On top of that, many postgres installations with reasonably secure configuration wouldn't grant portage access anyway. As it isn't hard at all to run a separate postgres instance (upstream is explicitly supporting it), I'd strongly recommend doing so even with network-sandbox being disabled. -- Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
Dnia 2014-05-13, o godz. 09:28:49 Andrew Savchenko birc...@gmail.com napisał(a): 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). Calling something a disaster just because it breaks one thing is unpleasant at least. This is a corner case with no good solution at the moment. Though it is entirely doable to make FEATURES=distcc and FEATURES=network-sandbox conflict, or the former disable the latter implicitly. As Rich noted, we do not enable distcc by default so there's no reason why we can't enable conflicting options by default. As far as distcc is concerned, I don't currently have time to work on it. This would probably require some kind of bridging -- or allowing distcc processes to escape the sandbox. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On 12/05/14 02:18, Davide Pesavento wrote: On Sun, May 11, 2014 at 11:42 PM, Michał Górny mgo...@gentoo.org 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. +1 I've been using all three of them since their introduction, without any problems. Thanks, Davide Same here. No Problems ever. Only if packages try to access the net, which we don't want anyway, you will have problems. Jusitn signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - -1 from me until Portage is capable of detecting if the user's operating system supports the FEATUREs, and informing them of this. I also agree with Ryan that the relevant Linux options should be added to the Gentoo Linux menu. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNwrVcACgkQRtClrXBQc7VW3AEAhl41o6THGN7MmZBw+8fr2rIh KhR3PEwaVmxVzTxoMt4BAK7wTlp22XrQd4mndJQLFVvitAHFNftideozWVkHqSkp =Pfv7 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
Am Montag, 12. Mai 2014, 13:15:35 schrieb Alexander Berntsen: -1 from me until Portage is capable of detecting if the user's operating system supports the FEATUREs, and informing them of this. I also agree with Ryan that the relevant Linux options should be added to the Gentoo Linux menu. Same opinion here, please * have portage detect the OS support (You have enabled FEATURES=x, but this is unsupported by your operating system. Disabling.) * add to Gentoo Linux kernel config menu Afterwards, +1 +1 +1 :) -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, May 12, 2014 at 8:59 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Am Montag, 12. Mai 2014, 13:15:35 schrieb Alexander Berntsen: -1 from me until Portage is capable of detecting if the user's operating system supports the FEATUREs, and informing them of this. I also agree with Ryan that the relevant Linux options should be added to the Gentoo Linux menu. Same opinion here, please * have portage detect the OS support (You have enabled FEATURES=x, but this is unsupported by your operating system. Disabling.) Portage currently prints a warning based on errno when the unshare(2) call fails for ipc-sandbox or network-sandbox. There is probably no need for fancier detection, but the message could probably be improved.
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, 12 May 2014 13:15:35 +0200 Alexander Berntsen berna...@gentoo.org wrote: - -1 from me until Portage is capable of detecting if the user's operating system supports the FEATUREs, and informing them of this. A flag being present or not in FEATURES does not mean anything, and if you're assuming that it does then you have a bug. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/05/14 17:23, Ciaran McCreesh wrote: A flag being present or not in FEATURES does not mean anything, and if you're assuming that it does then you have a bug. Please try to stay on topic, and don't obfuscate your posts needlessly. Note that I will not be responding to comments like these from you in the future. I am familiar with your modus operandi by now, and am far too busy for it. If you have an actual question or opinion, please make it, and I shall respond to it if that makes sense. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNw7PEACgkQRtClrXBQc7WXjQD/Qat4O5OnEH48jrNyHXpbsUTr M+UujFHqHLc9KBz3dNoA/RWh5zbh7j8TUeeMxqvlnRZ4/ggki1rza/KVr8nyiT+B =a62v -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, 12 May 2014 17:46:57 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 12/05/14 17:23, Ciaran McCreesh wrote: A flag being present or not in FEATURES does not mean anything, and if you're assuming that it does then you have a bug. Please try to stay on topic, and don't obfuscate your posts needlessly. This is on-topic, and it tells you exactly what you need to know to understand why your objection is irrelevant. But if you would like it made simpler, but less precise: if you are looking at FEATURES for anything that is not purely Portage internals, you are doing something wrong. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
-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-
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, May 12, 2014 at 12:07 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: 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. So, in theory with a separate network namespace I would think that the ebuild could start postgresql which could listen on any port regardless of the fact that it is running already, because the port would not be used within its own namespace. Anything started within the namespace that tried to connect to postgresql would end up talking to the version contained within the namespace. That could be useful in a lot of testing scenarios. However, I don't know if portage actually makes the network namespace that it creates useful - I don't know if it contains any interfaces, or if they are initialized/etc. Rich
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, May 12, 2014 at 11:59 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 12 May 2014 17:46:57 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 12/05/14 17:23, Ciaran McCreesh wrote: A flag being present or not in FEATURES does not mean anything, and if you're assuming that it does then you have a bug. Please try to stay on topic, and don't obfuscate your posts needlessly. This is on-topic, and it tells you exactly what you need to know to understand why your objection is irrelevant. But if you would like it made simpler, but less precise: if you are looking at FEATURES for anything that is not purely Portage internals, you are doing something wrong. The idea would be to check for the necessary kernel features from portage backend code, not from ebuild code.
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, 12 May 2014 12:44:38 -0400 Mike Gilbert flop...@gentoo.org wrote: On Mon, May 12, 2014 at 11:59 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 12 May 2014 17:46:57 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 12/05/14 17:23, Ciaran McCreesh wrote: A flag being present or not in FEATURES does not mean anything, and if you're assuming that it does then you have a bug. Please try to stay on topic, and don't obfuscate your posts needlessly. This is on-topic, and it tells you exactly what you need to know to understand why your objection is irrelevant. But if you would like it made simpler, but less precise: if you are looking at FEATURES for anything that is not purely Portage internals, you are doing something wrong. The idea would be to check for the necessary kernel features from portage backend code, not from ebuild code. Why, though? FEATURES doesn't give meaningful information to anything other than Portage internals, so it doesn't matter. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, May 12, 2014 at 12:46 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 12 May 2014 12:44:38 -0400 Mike Gilbert flop...@gentoo.org wrote: On Mon, May 12, 2014 at 11:59 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 12 May 2014 17:46:57 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 12/05/14 17:23, Ciaran McCreesh wrote: A flag being present or not in FEATURES does not mean anything, and if you're assuming that it does then you have a bug. Please try to stay on topic, and don't obfuscate your posts needlessly. This is on-topic, and it tells you exactly what you need to know to understand why your objection is irrelevant. But if you would like it made simpler, but less precise: if you are looking at FEATURES for anything that is not purely Portage internals, you are doing something wrong. The idea would be to check for the necessary kernel features from portage backend code, not from ebuild code. Why, though? FEATURES doesn't give meaningful information to anything other than Portage internals, so it doesn't matter. I'm not sure what you mean, but maybe we are just thinking about it differently. When FEATURES=network-sandbox, the kernel must have CONFIG_NET_NS enabled or the unshare(2) call will fail. We should probably emit an error message advising the user to enable the kernel option or disable the network-sandbox feature. This should happen when we call unshare() and that fails with errno == EINVAL.
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
Mike Gilbert wrote: On Mon, May 12, 2014 at 12:46 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why, though? We should probably emit an error message advising the user to enable the kernel option or disable the network-sandbox feature. This should happen when we call unshare() and that fails with errno == EINVAL. Why? Because that would be a sensible error message. //Peter
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
Dnia 2014-05-12, o godz. 12:40:42 Rich Freeman ri...@gentoo.org napisał(a): However, I don't know if portage actually makes the network namespace that it creates useful - I don't know if it contains any interfaces, or if they are initialized/etc. It sets up a private loopback (alike 'ifconfig lo up') that gets the standard addresses. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
Dnia 2014-05-12, o godz. 12:07:11 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org napisał(a): 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. How can you assume that the tests are perfectly safe? What do the tests do exactly? 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. I'd rather not get into allowing exceptions for the rule without knowing a good use case first. I can expand on that once the previous question is answered. I wouldn't call spawning a daemon that close to insanity. For those who haven't seen such a thing yet -- dev-python/pymongo is an example where I fixed a similar issue (writing into production database). Though it's bit hacky since I needed a way to bind to a random free port -- with network namespaces it'd be easier as Rich noted, since the ebuild would have all ports free. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/12/2014 01:08 PM, Michał Górny wrote: Dnia 2014-05-12, o godz. 12:07:11 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org napisał(a): 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. How can you assume that the tests are perfectly safe? What do the tests do exactly? As stated just below, the tests are not poorly written. All testing is done in a test DB which is different from the production DB. 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. I'd rather not get into allowing exceptions for the rule without knowing a good use case first. I can expand on that once the previous question is answered. I wouldn't necessarily ask for this either, I'm just bringing to the attention of the ML as this could be an issue for more than metasploit and pymongodb. I wouldn't call spawning a daemon that close to insanity. For those who haven't seen such a thing yet -- dev-python/pymongo is an example where I fixed a similar issue (writing into production database). Though it's bit hacky since I needed a way to bind to a random free port -- with network namespaces it'd be easier as Rich noted, since the ebuild would have all ports free. That would be nice, can we do the network namespaces so that I at least don't have to bind to a random port? That alone would be a major improvement in usability. Personally, I would love to be able to talk to localhost outside the ebuild, but if everyone agrees that is too dangerous then I don't feel I am qualified to disagree. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTcQNMAAoJEKXdFCfdEflKuNEP/34dIuiPCFLqLBUnCPJDQ3JW RVrhfOoqLyyixS18rYqTNeTDBDBrnICtsZ7T47ycs9fKbN81cgSUOrMQw/qai8/v jDBPUNb9YTs2BJ22GtNw0OBPbGc81GEBLc36P5etS5ymDPwbThSsSTo90cOiZweS IQgHkN0ZUDxmgG/q53GSU1IONZzNU3nSt+yrd90h40Vbo2PuAC4O+fz0m3jEGV5C WX+h5W+BCLStPerOV/VNySqQ3uo5poi3wXc3o4ojgpH1ejXo0dJ4fn6KHZxema52 JH3K3VSn2Mr60wo/43kDRmA4TtYSNbxMAH2aykAJ3WklZf3a82O0Z+++Sad84zTJ khpJwMHJkWAGTRibxpLIQ4lSjuCwAD/WCTHRw2i8PQPWtDJNGETaGFiBwtNZRexe 2kXZbpr3TqdwfY9WgDU4pB4QpRk7UYKSVgktSIU+yY4zGH6R2LaoUs/uQDntP/1F RYtdxV4glZ8qeOq9hmT3hnzVt/Pvj/sm+oPVJRRurz+X5FJIBGUkEFzqIXisE12E 3xUxsMQfjfOh4Io5y45iQjoYw30GdNU2t47IhTMHy1Cg9ZW5Lodx5qYiXy6JOww9 rLXVYa7u8f9emrQZChDd3+OeODU09O/YaakNhHv6gxpcVAOj9G9BMKMh0LHxSY6P X0lKgUDxyzYSDNBhaiCn =Vi4y -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
Dnia 2014-05-12, o godz. 13:22:20 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/12/2014 01:08 PM, Michał Górny wrote: Dnia 2014-05-12, o godz. 12:07:11 Rick \Zero_Chaos\ Farina zeroch...@gentoo.org napisał(a): 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. How can you assume that the tests are perfectly safe? What do the tests do exactly? As stated just below, the tests are not poorly written. All testing is done in a test DB which is different from the production DB. I don't know postgresql well enough but does the test db reside in temporary build directory? That is, can you guarantee that: 1) it will never ever collide with user's database, 2) it will be properly cleaned up even if the test suite terminates unexpectedly? I wouldn't call spawning a daemon that close to insanity. For those who haven't seen such a thing yet -- dev-python/pymongo is an example where I fixed a similar issue (writing into production database). Though it's bit hacky since I needed a way to bind to a random free port -- with network namespaces it'd be easier as Rich noted, since the ebuild would have all ports free. That would be nice, can we do the network namespaces so that I at least don't have to bind to a random port? That alone would be a major improvement in usability. FEATURES=network-sandbox == network namespaces. I'd say a reasonable assumption would be to Gentoo-reserve a port range for ebuild use, and use a port in that range. When network-sandbox becomes the default, it will be perfectly safe. Before that, it will be reasonably safe :). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Mon, May 12, 2014 at 1:22 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: That would be nice, can we do the network namespaces so that I at least don't have to bind to a random port? That alone would be a major improvement in usability. From my very limited understanding of network namespaces, when you create one it doesn't contain any interfaces. You can then create virtual interfaces inside, and potentially bridge them to other interfaces outside. If you just don't bridge it, then you would get what amounts to a loopback interface inside the namespace. If you do bridge it, then that interface still gets its own IP. Nothing would be listening on a new virtual interface, so you could bind to any port you want to (though I think you'd still need to be root to bind to a low port/etc). Personally, I would love to be able to talk to localhost outside the ebuild, but if everyone agrees that is too dangerous then I don't feel I am qualified to disagree. I guess the question is, why? I suppose you could provide a way for ebuilds to disable the use of namespaces, but I'm not sure if that is worth building, or even is desirable. (And yes, I realize this would be PM-specific if we did it.) Rich
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
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
Re: [gentoo-dev] RFC: enabling ipc-sandbox network-sandbox by default
On Sun, May 11, 2014 at 11:42 PM, Michał Górny mgo...@gentoo.org 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. +1 I've been using all three of them since their introduction, without any problems. Thanks, Davide
