Re: [gentoo-dev] Reviving the Sandbox project

[Brian Dolbec]

On Fri, 22 Sep 2017 15:06:49 +0000
James McMechan <james_mcmechan@×××××××.com> wrote:

> On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman <rich0@g.o>
> wrote:
> >On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich
> ><slyfox@g.o> wrote:
> >>
> >> Some other distros try harder to isolate build environment either
> >> through chroot and/or private mount/user/network namespace that
> >> contains only explicitly specified files in build environment.
> >>
> >> That would require more cooperation from package manager to fetch
> >> list of all visible depends.
> >>
> >
> >I definitely think this is something that would be VERY useful to
> >have, because it makes build-time dependency issues almost
> >impossible.
> >
> >However, you don't need that complete solution just to have a
> >sandbox. You could simply create a container with the entire
> >contents of the main filesystem, but read-only, with the exception
> >of the build area. That would replicate the functionality of the
> >current sandbox and would be easier than building out just the files
> >specified in the dependencies.
> >
> >The main issue I see with making it dependency aware is performance.
> >You would need to walk all the dependencies and their run-time
> >dependencies, and the system set, and then individually bind-mount
> >the files that belong to them read-only into the container.  That
> >isn't necessarily difficult, but I imagine that it would be slow.
> >Walking the dependencies obviously already happens during resolution
> >so that could probably be cached.  You could also cache the list of
> >files for the system set, and you could even maintain a snapshot of
> >these that is used as the base of the container (somebody would need
> >to work out the savings of doing this vs the cost of updating it
> >every time a system set package changes).
> >
> >However, the main thing I wanted to point out is that you don't need
> >a dependency-aware solution to just replace the existing sandbox.
> >
> >> I like clear sandbox error reporting.
> >
> >As far as error reporting goes, you would get kernel-level errors
> >like attempting to write to a read-only bind mount, or trying to
> >read a file that doesn't exist.  To a portage dev it should be
> >pretty obvious what is going on.  You could add canned text to the
> >portage error output at the end.  I'm not sure how visible the
> >problems would be to portage except to the degree that the build
> >system makes them visible
> >- it would just see make terminate with a non-zero return.
> >
> >I would think that containers would be almost completely bug-free
> >though.  The only thing I could see as an issue is some build system
> >that relies on IPC with the host, network access, etc.  Namespaces
> >themselves are very robust, and the kernel already looks at every
> >process as belonging to a set of namespaces even in the default case
> >where you only have one set of namespaces on the system, so they
> >don't involve different code paths/etc.
> >
> >--
> >Rich
>
> Another possibility, could be to have the sandbox be an overlayfs
> not of the build directory but of the entire system starting at "/"
> and stick that into the container, only CLONE_NEWNS looks to be
> needed.
>
> A container with all writes going to the upper layer of the overlay
> could be safe against even #RM -RF / and other disasters, while still
> tracking what is happening during the build.
>
> Should performance be too much of a problem having a bind mount of
> the build directory on top of the overlay should give normal
> performance to everything that is obeying good practice.
>
> After the build completes the directory that was mounted as upper
> could be scanned to find any wayward writes that had occurred...
>
> This would not require LD_PRELOAD or ptrace eliminating most of the
> "high magic" currently used.
>
> Just yesterday I had a lot of ptrace failures while trying something
> odd with ROOT= and custom USE
>
> Jim McMechan

I kinda like this idea, It looks to me to have pretty much all the
benefits of a sandbox and nearly none of the drawbacks.

Sounds like it should get more research into this idea, figure out it's
limitations and if there are any caveats.

-- 
Brian Dolbec <dolsen>