Re: [gentoo-dev] Reviving the Sandbox project

[Alec Warner <antarus@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

On Fri, Sep 22, 2017 at 5:51 PM, R0b0t1 <r030t1@gmail.com> wrote:

> On Thu, Sep 21, 2017 at 2:56 PM, Michał Górny <mgorny@gentoo.org> 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
sandbox isn't designed to be a "security boundary" (its trivially
defeat-able[1]). Instead its designed to be a fairly straightforward
detector of 'anomalous' 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.

[1] So defeatable in fact that ebuilds have an API to modify the boundaries
of the sandbox and even if the enforcement was stronger (e.g. via
seccomp-bpf) there is still the idea that ebuilds can rather arbitrarily
alter the sandbox boundaries...so nothing really prevents application code
from also altering the boundaries in the current design; I suspect fixing
this would be fairly tricky without some major changes.

-A


> In the sense that Portage can in its entirely be isolated in various
> ways (user groups, containers, virtual machines, etc) I am not sure
> adding another layer is the most expedient option, especially if it is
> hard to maintain.
>
> I once saw Java developers talking about introducing changes to an
> enterprise program by not modifying the source, but keeping the source
> as is, and then maintaining a set of reflection-based patches that
> would modify the program after it was loaded but before it was run.
> This did not make sense to me, and it seems a lot like what is being
> done with the sandbox.
>
> In some cases that can make sense, I suppose. I am not a very smart
> man, so I would not know the necessary burden of proof.
>
> Respectfully,
>      R0b0t1
>
>

[-- Attachment #2: Type: text/html, Size: 2834 bytes --]