On 2017-09-22 10:03 AM, Brian Dolbec wrote: > On Fri, 22 Sep 2017 15:06:49 +0000 > James McMechan <james_mcmec...@hotmail.com> wrote: > >> On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman <ri...@gentoo.org> >> wrote: >>> On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich >>> <sly...@gentoo.org> 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. >
I haven't had time as of yet to look in to it, but theoretically one could use seccomp with bpf to make a more robust sandbox, though you might not get as nice error reporting as we have now. Also apparmor could theoretically be used to make a nice sandbox, but I suspect that could come with other implications.
