[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Reviving the Sandbox project
From:       R0b0t1 <r030t1 () gmail ! com>
Date:       2017-09-23 5:18:15
Message-ID: CAAD4mYjEx1ZXLKerbEKZ5oJ_EO0tkg6Jn55oVy64JbeK3E1YmA () mail ! gmail ! com
[Download RAW message or body]

On Fri, Sep 22, 2017 at 5:01 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> On 09/22/2017 05:51 PM, R0b0t1 wrote:
>> On Thu, Sep 21, 2017 at 2:56 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.o=
rg> wrote:
>>> [1]:https://wiki.gentoo.org/wiki/Project:Sandbox
>>>
>>
>> I think I understand, in principle, why a sandbox could be useful, but
>> would it not be more productive to follow up with projects which do
>> unexpected things to ask that they not do those things?
>>
>
> The sandbox isn't a security feature, it's more of a QA tool. How do you
> *know* when the upstream project does something wrong? See, for example,
>

I was aware of this part. I suggested sandboxing mechanisms which were
security related not for security purposes, but due to the fact that
their original design goals makes them more comprehensive. As a bonus,
they already exist.


On Fri, Sep 22, 2017 at 5:05 PM, Alec Warner <antarus@gentoo.org> wrote:
>
>
> On Fri, Sep 22, 2017 at 5:51 PM, R0b0t1 <r030t1@gmail.com> wrote:
>>
>> On Thu, Sep 21, 2017 at 2:56 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.o=
rg> wrote:
>> > [1]:https://wiki.gentoo.org/wiki/Project:Sandbox
>> >
>>
>> I think I understand, in principle, why a sandbox could be useful, but
>> would it not be more productive to follow up with projects which do
>> unexpected things to ask that they not do those things?
>
>
> So step one is figuring out what those things are. So the LD_PRELOAD sand=
box
> isn't designed to be a "security boundary" (its trivially defeat-able[1])=
.
> Instead its designed to be a fairly straightforward detector of 'anomalou=
s'
> behavior. It works by intercepting file-operations and comparing them
> against a whitelist.
>
> You can't tell people do stop doing unexpected things if you don't know
> their software is doing unexpected things.
>

Right, I suppose a sandboxing mechanism is the best way to detect
those changes. Is it necessary for it to be implemented with something
like ptrace or ld tricks? Like above, I ask because other mechanisms
are more comprehensive.

The mechanism used to implement containers, in particular, is
extremely interesting because it does (more or less) exactly what is
wanted. Look for the CLONE_NEW* options in `man 2 clone`. It is
possible containers are the best interface to this syscall, but I am
not sure how to evaluate them in the context they would be used.

Respectfully,
     R0b0t1

[prev in list] [next in list] [prev in thread] [next in thread]