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