On Fri, Sep 22, 2017 at 5:51 PM, R0b0t1 <r03...@gmail.com> wrote: > On Thu, Sep 21, 2017 at 2:56 PM, Michał Górny <mgo...@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 > >
