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