Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
Hi, Ryan Hill wrote: Probably best to make FEATURES=distcc disable network-sandbox then. People enabling it are explicitly saying they want to access the network. Do you really think it is a good behavior to automatically disable something you can call a security feature? At least there should be a warning, not? Think about situations where the user just know network-sandbox is important, because it will protect my system from unwanted modifications (the thing where the test suite for example will write to the local, productive, database server...) and therefore explicitly enable that feature by hand. But the user is *also* using distcc to speed up the compilation/update time in his/her network. The user maybe knows that distcc is using network, but he/she might be surprised that it won't work together with the network-sandbox feature. If we now silently disable network-sandbox because the user also set distcc he/she might be even more surprised when he/she noticed that his/her local productive database system was accessed by emerge though he/she enabled network-sandbox feature to prevent this (but which was automatically disabled without a warning). Because it is security relevant and the impact could be a real problem I won't even show just a warning the user could miss. If network-sandbox *and* distcc are both set, emerge should fail complaining about the problem. This is something the user should be aware of and must be solved by hand. So if we decide to enable the network-sandbox feature by default (which we should do), users also using distcc must take action. And if in future we will solve the problem so that both features can be used together, we should send out a news item for people using the distcc feature telling them Now you can re-enable (the default) network-sandbox feature... -Thomas
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, May 15, 2014 at 4:12 AM, Thomas D. whi...@whissi.de wrote: Hi, Ryan Hill wrote: Probably best to make FEATURES=distcc disable network-sandbox then. People enabling it are explicitly saying they want to access the network. Do you really think it is a good behavior to automatically disable something you can call a security feature? At least there should be a warning, not? I think you are reading much further into Ryan's statement than he intended. Think about situations where the user just know network-sandbox is important, because it will protect my system from unwanted modifications (the thing where the test suite for example will write to the local, productive, database server...) and therefore explicitly enable that feature by hand. But the user is *also* using distcc to speed up the compilation/update time in his/her network. The user maybe knows that distcc is using network, but he/she might be surprised that it won't work together with the network-sandbox feature. If we now silently disable network-sandbox because the user also set distcc he/she might be even more surprised when he/she noticed that his/her local productive database system was accessed by emerge though he/she enabled network-sandbox feature to prevent this (but which was automatically disabled without a warning). Because it is security relevant and the impact could be a real problem I won't even show just a warning the user could miss. If network-sandbox *and* distcc are both set, emerge should fail complaining about the problem. This is something the user should be aware of and must be solved by hand. So if we decide to enable the network-sandbox feature by default (which we should do), users also using distcc must take action. And if in future we will solve the problem so that both features can be used together, we should send out a news item for people using the distcc feature telling them Now you can re-enable (the default) network-sandbox feature... -Thomas
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 13:12:30 +0200 Thomas D. whi...@whissi.de wrote: Ryan Hill wrote: Probably best to make FEATURES=distcc disable network-sandbox then. People enabling it are explicitly saying they want to access the network. Do you really think it is a good behavior to automatically disable something you can call a security feature? At least there should be a warning, not? Sandboxing isn't about security. It's about catching mistakes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 16:48:24 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Sandboxing isn't about security. It's about catching mistakes. Ciaran has a point here. Thomas, you assumed that network-sandbox is the only thing stopping an ebuild from accessing local services or the internet. However, even with network-sandbox being enabled such behaviour would still constitue a major bug which would be fixed by the devs. So yes, network-sandbox (and same goes for ipc-sandbox) is mainly a debugging aid for developers which will help them spot such problems more easily. -- Regards, Luis Ressel signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
Ciaran McCreesh: Sandboxing isn't about security. Sure it is.
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
Hi, Ciaran McCreesh wrote: Sandboxing isn't about security. It's about catching mistakes. From Wikipedia (http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29): In computer security, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers, untrusted users and untrusted websites network-sandbox is using unshare() syscalls to separate... not? But when I wrote my mail I was referring to Michal's statements in http://thread.gmane.org/gmane.linux.gentoo.devel/91131. He is explicitly listing improving security... -Thomas
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 20:35:41 +0200 Thomas D. whi...@whissi.de wrote: Ciaran McCreesh wrote: Sandboxing isn't about security. It's about catching mistakes. From Wikipedia (http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29): In computer security, a sandbox is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers, untrusted users and untrusted websites network-sandbox is using unshare() syscalls to separate... not? Not for security reasons: sandbox (the way it is used on Gentoo) does nothing against a malicious ebuild or a malicious package. Instead, it simply catches certain common mistakes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? There is a big difference between the sandbox utility (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The former uses an LD_PRELOAD hack to intercept libc functions, and does not provide any security benefit. The latter options create separate namespaces in the kernel, which is probably a lot more secure.
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, 15 May 2014 14:44:58 -0400 Mike Gilbert flop...@gentoo.org wrote: On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? There is a big difference between the sandbox utility (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The former uses an LD_PRELOAD hack to intercept libc functions, and does not provide any security benefit. The latter options create separate namespaces in the kernel, which is probably a lot more secure. Secure against what? Malicious ebuilds? Malicious packages? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, May 15, 2014 at 2:48 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 14:44:58 -0400 Mike Gilbert flop...@gentoo.org wrote: On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? There is a big difference between the sandbox utility (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The former uses an LD_PRELOAD hack to intercept libc functions, and does not provide any security benefit. The latter options create separate namespaces in the kernel, which is probably a lot more secure. Secure against what? Malicious ebuilds? Malicious packages? Secure against unauthrorized network access during phases where network-sandbox is effective. I am aware that this is a very small benefit given that the ebuild or build system can do lots of things locally without network access, or install some file that accesses the network later. ipc-sandbox probably has some similar security benefit, but I don't understand it as well.
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Thu, May 15, 2014 at 12:01 PM, Mike Gilbert flop...@gentoo.org wrote: On Thu, May 15, 2014 at 2:48 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 14:44:58 -0400 Mike Gilbert flop...@gentoo.org wrote: On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 15 May 2014 17:15:32 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: Sandboxing isn't about security. Sure it is. Then where do the bug reports for all the security violations possible with sandbox go? There is a big difference between the sandbox utility (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The former uses an LD_PRELOAD hack to intercept libc functions, and does not provide any security benefit. The latter options create separate namespaces in the kernel, which is probably a lot more secure. Secure against what? Malicious ebuilds? Malicious packages? Secure against unauthrorized network access during phases where network-sandbox is effective. I am aware that this is a very small benefit given that the ebuild or build system can do lots of things locally without network access, or install some file that accesses the network later. ipc-sandbox probably has some similar security benefit, but I don't understand it as well. I think we are way off topic here folks ;) -A
[gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Tue, 13 May 2014 19:11:18 +0200 Michał Górny mgo...@gentoo.org wrote: 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. Probably best to make FEATURES=distcc disable network-sandbox then. People enabling it are explicitly saying they want to access the network. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Sun, 11 May 2014 23:42:38 +0200 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. 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. [snip] All three of these require kernel support. It might be a good idea to add the needed options to that Gentoo Linux menu we have in gentoo-sources and enable them by default. I think it would be non-obvious to a new user that they would have to enable network and ipc namespaces for portage to work properly out of the box (and if they disable the latter they get a bunch of cryptic Unable to unshare: EINVAL messages every time they build something which isn't very helpful). Do we know of any packages broken by these features? Maybe we can add them to the dev profiles for a while before we dump it on everyone. Otherwise +1. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Mon, 12 May 2014 00:47:17 -0600 Ryan Hill rh...@gentoo.org wrote: 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. All three of these require kernel support. It might be a good idea to add the needed options to that Gentoo Linux menu we have in gentoo-sources and enable them by default. Right, this skipped my mind when I enabled them yesterday; this should be documented, as well as have Portage check for missing support and test it and bail out with a proper error message if it doesn't already. Which options are these in particular? I'll cook a patch with them. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
On Mon, 12 May 2014 11:39:10 +0200 Tom Wijsman tom...@gentoo.org wrote: On Mon, 12 May 2014 00:47:17 -0600 Ryan Hill rh...@gentoo.org wrote: 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. All three of these require kernel support. It might be a good idea to add the needed options to that Gentoo Linux menu we have in gentoo-sources and enable them by default. Right, this skipped my mind when I enabled them yesterday; this should be documented, as well as have Portage check for missing support and test it and bail out with a proper error message if it doesn't already. Which options are these in particular? I'll cook a patch with them. I believe they are CONFIG_IPC_NS, CONFIG_NET_NS, and CONFIG_CGROUPS. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default
Hi, I do not know if this came up... glibc must be bumped first[1]. Alon [1] https://bugs.gentoo.org/show_bug.cgi?id=504032
