1 |
On Thu, May 15, 2014 at 12:01 PM, Mike Gilbert <floppym@g.o> wrote: |
2 |
|
3 |
> On Thu, May 15, 2014 at 2:48 PM, Ciaran McCreesh |
4 |
> <ciaran.mccreesh@××××××××××.com> wrote: |
5 |
> > On Thu, 15 May 2014 14:44:58 -0400 |
6 |
> > Mike Gilbert <floppym@g.o> wrote: |
7 |
> >> On Thu, May 15, 2014 at 1:17 PM, Ciaran McCreesh |
8 |
> >> <ciaran.mccreesh@××××××××××.com> wrote: |
9 |
> >> > On Thu, 15 May 2014 17:15:32 +0000 |
10 |
> >> > hasufell <hasufell@g.o> wrote: |
11 |
> >> >> Ciaran McCreesh: |
12 |
> >> >> > Sandboxing isn't about security. |
13 |
> >> >> > |
14 |
> >> >> |
15 |
> >> >> Sure it is. |
16 |
> >> > |
17 |
> >> > Then where do the bug reports for all the "security violations" |
18 |
> >> > possible with sandbox go? |
19 |
> >> > |
20 |
> >> |
21 |
> >> There is a big difference between the sandbox utility |
22 |
> >> (sys-apps/sandbox) and the network-sandbox/ipc-sandbox features. The |
23 |
> >> former uses an LD_PRELOAD hack to intercept libc functions, and does |
24 |
> >> not provide any security benefit. The latter options create separate |
25 |
> >> namespaces in the kernel, which is probably a lot more secure. |
26 |
> > |
27 |
> > "Secure" against what? Malicious ebuilds? Malicious packages? |
28 |
> > |
29 |
> |
30 |
> Secure against unauthrorized network access during phases where |
31 |
> network-sandbox is effective. I am aware that this is a very small |
32 |
> benefit given that the ebuild or build system can do lots of things |
33 |
> locally without network access, or install some file that accesses the |
34 |
> network later. |
35 |
> |
36 |
> ipc-sandbox probably has some similar security benefit, but I don't |
37 |
> understand it as well. |
38 |
> |
39 |
> |
40 |
I think we are way off topic here folks ;) |
41 |
|
42 |
-A |